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Scope 



The present document provides the stage 3 description of the NGN integrated IPTV subsystem based on the architecture 
and stage 2 information flows described in TS 182 028 [4]. 

The protocol enhancements will form the scope of new or enhanced protocol specifications. 

The interaction with other NGN subsystems such as PES, IMS and RAGS will be considered. 

The current release is applicable to: 

• the interface between the User Equipment (UE) and the SD&S; 

• the interface between the User Equipment (UE) and Gustomer facing IPTV AppHcations (GF-IPTV-Apps); 

• the interface between the User Equipment (UE) and IPTV Gontrol (IPTV-G); 

• the interface between the User Equipment (UE) and Media Gontrol Functions (MGF); 

• the interface between the User Equipment (UE) and Media Delivery Functions (MDF); 

• the interface between the Gustomer facing IPTV Applications (GF-IPTV-Apps) and IPTV Gontrol (IPTV-G); 

• the interface for access to IPTV User Data Function (IPTV UDF); 

• the interface between the IPTV Gontrol (IPTV-G) and Media Gontrol Functions (MGF); 

• the interface for access to NGN User Data Access Function (NGN UDAF). 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI ES 282 001 (Release 3): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); NGN Functional Architecture". 

[2] ETSI ES 282 004 (Release 3): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); NGN Functional Architecture; Network 
Attachment Sub-System (NASS)". 

[3] ETSI ES 282 003 (Release 3): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); Resource and Admission Gontrol Sub-System 
(RAGS): Functional Architecture". 

[4] ETSI TS 182 028 (Release 3): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); NGN integrated IPTV subsystem Architecture". 
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[5] ETSI TS 102 034 (Vl.4.1): "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based 

DVB Services over IP Based Networks". 

[6] IETF RFC 2326 (April 1998): "Real Time Streaming Protocol (RTSP)". 

[7] IETF RFC 2617 (June 1996): " HTTP Authentication: Basic and Digest Access Authentication". 

[8] ETSI TS 102 539: "Digital Video Broadcasting (DVB); Carriage of Broadband Content Guide 

(BCG) information over Internet Protocol (IP)". 

[9] IETF RFC 2616 (June 1999): "Hypertext Transfer Protocol - HTTP/1.1". 

[10] IETF RFC 3428 (December 2002): "Session Initiation Protocol (SIP) Extension for Instant 

Messaging". 

[11] ETSI TS 183 041 (Release 2): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); Messaging service using the IP Multimedia (IM) 
Core Network (CN) subsystem; Stage 3: Protocol specifications [Endorsement of 3GPP TS 24.247 
Release 6] " . 

[12] IETF RFC 3856 (2004): "Presence Event Package for the Session Initiation Protocol (SIP)". 

[13] ETSI TS 182 008 (Release 2): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); Presence Service; Architecture and functional 
description [Endorsement of 3 GPP TS 23.508 Release 7 and 
OM A- AD-Presence-SIMPLE- V 1 -0] " . 

[14] IETF RFC 4662 (August 2006): "A Session Initiation Protocol (SIP) Event Notification Extension 

for Resource Lists". 

[15] IETF RFC 4825 (May 2007): "The Extensible Markup Language (XML). Configuration Access 

Protocol (XCAP)". 

[16] IETF RFC 5025 (December 2007): "Presence Authorization Rules". 

[17] ETSI TS 183 063 (Release 3): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification". 

[18] IETF RFC 3265 (June 2002): "Session Initiation Protocol (SlP)-Specific Event Notification". 

[19] IETF RFC 1321 (April, 1992): "The MD5 Message-Digest Algorithm". 

[20] IETF RFC 3376 (October 2002): "Internet Group Management Protocol, Version 3". 

[21] IETF RFC 3810 (June 2004): "Multicast Listener Discovery Version 2 (MLDv2) for Ipv6". 

[22] ETSI TS 183 017 (Release 3): "Telecommunications and Internet Converged Services and 

Protocols for Advanced Networking (TISPAN); Resource and Admission Control: DIAMETER 
protocol for session based policy set-up information exchange between the Application Function 
(AF) and the Service Policy Decision Function (SPDF); Protocol specification". 

[23] IETF RFC 4585 (July 2006): "Extended RTP Profile for Real-time Transport Control Protocol 

(RTCP)-Based Feedback (RTP/AVPF)". 

[24] IETF RFC 4588 (July 2006): "RTP Retransmission Payload Format". 

[25] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[26] ETSI TS 184 009 (Release 2): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN) Rules covering the use of TV URIs for the 
Identification of Television Channels". 

[27] IETF RFC 361 1 : "RTP Control Protocol Extended Reports (RTCP XR)". 

[28] IETF RFC 5760: "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions 

with Unicast Feedback" . 
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[29] IETF RFC 3550: "RTP: A Transport Protocol for Real-Time Applications". 

[30] IETF RFC 3926: "FLUTE - File Delivery over Unidirectional Transport". 

[31] W3C Recommendation (2002): "XHTML^m i .0 The Extensible HyperText Markup Language 

(Second Edition)". 

[32] W3C Candidate Recommendation (2007): "Cascading Style Sheets, level 2 Revision 1 (CSS 2.1) 

Specification" . 

[33] W3C Candidate Recommendation: "CSS TV Profile 1.0". 

[34] ISO/IEC International Standard 16262 (2002): "Information technology - ECMA Script language 

specification" . 

[35] W3C Recommendation: "Document Object Model (DOM) Level 2 Core Specification". 

NOTE Available at http://www.w3.Org/DOM/DOMTR#dom2 

[36] W3C Candidate Recommendation: "XMLHttpRequest". 

[37] Void. 

[38] Void. 

[39] Void. 

[40] IETF RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax". 

[41] IETF RFC 2818: "HTTP Over TLS". 

[42] Void. 

[43] Void. 

[44] IETF RFC 5576: "Source-Specific Media Attributes in the Session Description Protocol (SDP)". 

[45] IETF RFC 3605: "Real Time Control Protocol (RTCP) attribute in Session Description 

Protocol (SDP)". 

[46] Void. 

[47] ETSI TS 181 016 (V3.3.1): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); Service Layer Requirements to integrate NGN Services and 
IPTV". 

[48] IETF RFC 1305: "Network Time Protocol (Version 3), Specification, Implementation and 

Analysis". 

[49] ETSI TS 184 002: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Identifiers (IDs) for NGN". 

[50] IETF RFC 4282: "The Network Access Identifier" . 

[51] CEA CEA-2014-A ERTA (2008): "Web-based Protocol Framework for Remote User Interface on 

UpnPTM Networks and the Internet (Web4CE)". 
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2.2 Informative references 



The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TR 187 013 (Release 3): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); Feasibility study on IPTV Security Architecture". 

[i.2] F. Boronat, J. Lloret, M. Garcia: "Multimedia group and inter-stream synchronization techniques: 

A comparative study", Elsevier Information Systems 34 (2009), pp. 108-131. 

[i.3] ITU-T Recommendation H. 7 60: "Overview of multimedia application frameworks for IPTV 

services". 

[i.4] ETSI TR 182 030 (Release 3): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); IPTV architecture, NGN based IPTV mapping or 
interconnect between IPTV systems". 

[i.5] Void. 

[i.6] ITU-T Recommendation G.l 14: "General Recommendations on the transmission quality for an 

entire international telephone connection. One-way transmission time". May 2003. 

[i.7] ETSI TS 102 727 (VI. 1.1): "Digital Video Broadcasting (DVB); Multimedia Home Platform 

(MHP) Specification 1.2.2". 

[i.8] W3C Recommendation Scalable Vector Graphics (SVG) 1.1 Specification. 

[i.9] W3C Recommendation Scalable Vector Graphics (SVG) Tiny 1.2 Specification. 

[i. 10] OMA, XHTML Mobile Profile v. 1 .2. 

[i. 1 1] W3C HTML5, W3C Working Draft. 

[i.l2] ETSI TS 182 019 (Release 3): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); Content Delivery Network (CDN) architecture - 
Interconnection with TISPAN IPTV architectures". 

[i.l 3] SCTE-130 part 3: "Digital Program Insertion - Advertising Systems Interfaces; Part 3: Ad 

Management Service (ADM) Interface". 

NOTE: Available at: http://www.scte.org/documents/pdf/standards/top%20ten/ANSI SCTE%20130- 
3%202009.pdf) . 

[i.l4] ITU-T Recommendation X.891: "Information technology - Generic applications of ASN.l: Fast 

infoset". 

[i.l5] ETSI TS 102 472: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content 

Delivery Protocols". 

[i.l6] ISO/IEC 23001: "Information technology - MPEG systems technologies". 

[i.l7] ETSI TS 187 003 (Release 3): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); NGN Security; Security Architecture". 
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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the following terms and definitions apply: 

NGN Integrated IPTV subsystem: IPTV subsystem integrated within TISPAN NGN architecture which provides 
advanced personalized interactive IPTV services 

UE (converged): end user device, e.g. set top box or enhanced TV, capable of supporting IPTV services and services 
provided by other NGN subsystems 



3.2 



Abbreviations 



For the purposes of the present document the abbreviations given in TS 182 028 [4] and the following apply: 

ADM Ad Management Service 

ADS Ad Decision Service 

ASF Application Server Function 

BC Broadcast 

BCG Broadband Content Guide 

BiM Binary MPEG format for XML 

BTV Broadcast TV 

CCF Cluster Controller Function 

CDF Content Delivery Function 

CDN Content Delivery Networks 

CDNCF Content Delivery Network Control Function 

CF Customer Facing 

CFIA Customer Facing IPTV Applications 

CoD Content on Demand 

CoD-MF Content on Demand Media Functions 

c-PVR Ghent PVR 

CR Content Recommendation 

CRS Content and service Recommendation Service 

CSS Cascading Style Sheets 

DHCP Dynamic Host Configuration Protocol 

DNS Domain Name System 

DVB Digital Video Broadcast 

DVBSTP Digital Video Broadcasting Service discovery and Selection Transport Protocol 

ECF Elementary Control Function 

EFF Elementary Forwarding Function 

EPG Electric Program Guide 

ESG Electronic Service Guide 

FB FeedBack 

FE Functional Entity 

FLUTE File Delivery over Unidirectional Transport 

GOP Group of pictures 

GUI Graphical User Interface 

HTTP HyperText Transfer Protocol 

ID IDentifier 

IGMP Internet Group Management Protocol 

IGMPv2 Internet Group Management Protocol version 2 

IGMPv3 Internet Group Management Protocol version 3 

IM Instant messaging 

IMS IP Multimedia Subsystem 

IPTV UDF IPTV User Data Function 

IPTV Internet Protocol Television 

IPTV-C IPTV Control 

Ipv4 Internet Protocol version 4 
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lUDF IPTV User Data Function 

LMB Linear Media Broadcast 

MBwTM Media Broadcast with Trick Modes 

MC MulitCast 

MCF Media Control Function 

MDF Media Delivery Function 

MF Media Function 

MLD Multicast Listener Discovery (protocol) 

MLDvl Multicast Listener Discovery version 1 

MLDv2 Multicast Listener Discovery version 2 

MM7 MMS protocol 

MMS Multimedia Messaging Service 

MSAS Synchronization Application Server 

NAI Network Access Identifier 

NGN Next Generation Network 

NPT Normal Play Time 

nPVR network-side Personal Video Recorder 

NTP Network Time Protocol 

OSA Open Service Access 

PCh Personalized Channel 

POIS Placement Opportunity Information Service 

PS Presence Server 

PUA Presence User Agent 

PVR Personal Video Recorder 

RACS Resources Admission Control Sub-system 

RET RETransmission 

RFC Request For Comments 

RLS Resource List Server 

RR Receiver Report 

RSI Receiver Summary Information 

RTCP Real Time Control Protocol 

RTCPSSM RTCP extension for Source Specific Multicast 

RTP Real Time transport Protocol 

RTSP Real Time Streaming Protocol 

SC Synchronization Client 

SCP Service Content Protection 

S-CSCF Serving Call Session Control Function 

SCTE Society of Cable Telecommunications Engineers 

SD&S Service Discovery and Selection 

SDES Source Description RTCP Packet 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

SIS Subscriber Information Service 

SMPP Short Message Peer-to-Peer 

SMS Short Message Service 

SMTP Simple Mail Transfer Protocol 

SOAP Simple Object Access Protocol 

SR Sender Report 

SSRC Synchronization SouRCe 

TCP Transmission Control Protocol 

TPF Transport Functions 

TsTV Time-shift TV 

UDAF User Data Access Function 

UDP User Datagram Protocol 

UE User Equipment 

UGC User Generated Content 

UPSF User Profile Server Function 

URI Uniform Resource Identifier 

URL Uniform Resource Locator 

UTC Coordinated Universal Time 

VBR Variable bitrate 

WEB4CE Web-based Protocol and Framework for Consumer Electronics 
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XCAP XML Configuration Access Protocol 

XDMS XML Data Management Server 

XML Extensible Markup Language 

XR extended Report 



Applicability 



The following clauses explain the concept and approach used to define the protocols for the NGN integrated IPTV 
subsystem. 



4.1 Concept and Approach 



This clause outlines concept and approach adopted in the present document. The approach is then applied to protocol 
selections, mapping to interfaces and protocol extensions. 

The present document focuses on defining protocols for flexible functional architecture described in [4], which can: 

• allow development of new IPTV subsystem in NGN; 

• integrate existing IPTV subsystem in NGN; 

• extend both to support other NGN services. 

In order to achieve high level of flexibility and support integration of existing subsystems, the work is focused on 
evaluating and endorsing protocols already defined for similar functions in [5] and other standard bodies. Protocol 
extensions are defined where applicable as well as overall applicability to the end-to-end architecture [4] . 

For example, recommendations are made how to integrate DVB compliant UE without modifications and DVB 
compliant system with minimal modification to the service layer. 

4.2 Overview 

The clause describes applicability of the protocols discussed further in the present document to reference points defined 
in TS 182 028 [4]. The overall functional architecture for the NGN integrated IPTV service conforms to [4]. 

Figure 1 presents mapping of protocols to interfaces in NGN integrated NGN-IPTV and to interworking with other 
NGN subsystems and common components. 
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NOTE: Xc and Xd are logical interfaces that can be decomposed into Dj and optionally Di, Ds or Iz interfaces 

depending on the location of the MOP or MDF as described in [4] clause 5.2.5 for Xc and clause 5.1 .6 for 
Xd. 

Figure 1 : Protocols mapped to NGN integrated IPTV functional architecture 
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Table 1: NGN integrated IPTV functional entities and protocols used on interfaces 



FEZ 
Reference 

.point 
(protocol) 


UE 


IPTV-C 


CFIA 


SD&S 


UPSF 


lUDF 


MCF 


MDF 


ECF/ 
EFF 


UE 




Ct2 

(RTSP), 

(HTTP, 

Optional) 


Tr 
(HTTP) 


Tr 

(HTTP, 

DVBSTP) 






Xc 

(RTSP, 

HTTP 

optional) 


Xd 
(UDP/ 

RTP 

/RTCP, 

HTTP, 

FLUTE 

optional) 


Dj, Di 

IGMP/ 

MLD 


IPTV-C 


Ct2 

(RTSP), 

(HTTP, 

Optional) 




Ss 
(HTTP) 




Sh 
(Diameter) 


Ud 

(not 

defined) 


Sa 
(RTSP) 






CFIA 


Tr 
(HTTP) 


Ss 
(HTTP) 


Sh 
(Diameter) 


Ss' 
(HTTP) 


— 


— 


— 


— 


— 


SD&S 


Tr 

(HTTP, 

DVBSTP) 




Ss' 
(HTTP) 














UPSF 


— 


Sh 
(Diameter) 


Sh 
(Diameter) 


— 


— 


— 


— 


— 


— 


lUDF 




Ud 

(not 

defined) 










Ud 

(not 

defined) 






MCF 


Xc 

(RTSP, 

HTTP 

optional) 


Sa 
(RTSP) 








Ud 

(not 

defined) 




Xp 

(not 

defined) 




MDF 


Xd 

(UDP/ 

RTP/RTC 

P, HTTP, 

FLUTE 

optional) 












Xp 

(not 

defined) 






ECF/ EFF 


— 


— 


— 


— 


— 


— 


— 


— 


— 



NOTE 1 : NGN integrated IPTV protocol model is required to comply with standards applicable for NGN integrated 
IPTV as defined below. 

NOTE 2: See clause 4.3.9 for more details on the Sync interface. 

Usage of the HTTP protocol across the following interfaces is described in clause 5: 

interface Tr; 

interface Xc; 

interface Xd; 

interface Ss, Ss'; 

interface Ct2 (Optional); 

interface Sync (Optional). 
Usage of the HTTP protocol for interactions between NGN Applications and UE is described in annex E. 
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Usage of the RTSP protocol across the following interfaces is described in clause 6: 

• interface Ct2; 

• interface Sa; 

• interface Xc. 

Usage of the IGMP/MLD protocol across the following interfaces is described in clause 7: 

• interface Dj, Di. 

Usage of the SIP protocol for interactions between NGN Applications and UE is described in the clause 8. 
Usage of the DVBSTP across the following interfaces is described in clause 9: 

• interface Tr. 

Usage of the RTP/RTCP protocol across the following interface is described in clause 10: 

• interface Xd; 

• interface Sync. 

Usage of the MPEG2 TS across the following interfaces is described in clause 10: 

• interface Xd; 

• interface Tr. 

NOTE 3: Applications can be transferred as private data streams inside MPEG2 TS. Applicability of MPEG2 TS to 
Tr interface is outside the current release. 

Usage of the AL-FEC protocol across the following interface is described in clause 10: 

• interface Xd. 

Usage of the FLUTE protocol across the following interface is described in clause 1 1 : 

• interface Xd (optional). 

Use of Diameter shall comply to the following specifications: 

• [22] and [3] for interface; 

• [3] for e2 interface; 

• [ 1 ] for Sh interfaces . 

4.3 Functional Entities 

The functional entities that constitute the NGN integrated IPTV subsystem are defined in TS 182 028 [4]. The following 
clauses summarize the functionality of each functional entity. 

4.3.1 User Equipment(UE) 

The UE is a functional entity that provides the user with access to IPTV services. 

4.3.2 Service Discovery and Selection (SD&S) 

The Service Discovery and Selection (SD&S) is a functional entity that provides description information for discovery 
of the service as well as information required for description and selection of IPTV services. 
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4.3.3 Customer Facing IPTV Applications (CF-IPTV-Apps) 

The Customer Facing IPTV Application (CFIA) is a functional entity that provides IPTV service provisioning, selection 
and authorization. 

4.3.4 IPTV Control (IPTV-C) 

The IPTV Control (IPTV-C) is a functional entity that checks if UE has been authorized by the Customer Facing IPTV 
Application to use IPTV Service Control and Delivery Functions (provides selection of the Media Control Function). 

4.3.5 Media Control Function (MCF) 

The Media Control Function (MCF) is a functional entity that provides the UE with functions required to control media 
flows and manages the MDFs under its control. 

4.3.6 Media Delivery Function (MDF) 

The Media Delivery Function (MDF) is a functional entity that delivers content data to the UE. 

4.3.7 IPTV User Data Function (IPTV UDF) 

IPTV user data (lUDF) functional entity is responsible for handling NGN integrated IPTV user data. 

4.3.8 NGN User Data Access Function (NGN UDAF) 

NGN Application User Data FE (NGN UDF) is a functional entity responsible for handling NGN application and user 
data. 

4.3.9 Inter-destination media synchronization entities 

Figure la shows the two functional entities involved in inter-destination media synchronization, i.e. the synchronization 
client (SC) and the media synchronization application server (MS AS). Optionally, there is also a Synchronisation 
Client' (SC). These functional entities are described in clauses 4.3.9.1, 4.3.9.2 and 4.3.9.3. 




Figure 1a: Functional entities and reference points for inter-destination media synchronization. 
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As described in TS 182 028 [4], there exist different mappings of the SC and MS AS onto the functional entities 
depicted in figure 1 . 

The mapping of the SC as an elementary function of the UE is aimed at small-scale deployments of services that require 
media synchronization and only if a limited number of UEs uses media synchronization. It reuses existing service 
initialization. 

The mapping of the SC as an adjunct function that may be co-resident with any of the appropriate elements of the 
Transport Processing Function is aimed at large-scale deployment of media synchronization. 

The process of inter-destination media synchronization involves two basic steps: 

1) Synchronization initiation 

2) Synchronization status information and settings instruction exchange 

NOTE: As the synchronization initiation is stateless, synchronization termination is not needed. 
Given these steps, the Sync reference point is decomposed as follows: 

• Synchronization initiation information is exchanged over the Tr reference point, using HTTP. 
Synchronization initiation information can also be exchanged over the Xc reference point, using RTSP/SDP. 

• Synchronization status information and delay information in the form of settings instruction is exchanged over 
the Xd reference points, using RTCP. 

RTCP reports with synchronization status information or synchronization settings instructions can be sent directly 
between UEs, if a direct communication channel between UEs already exists. In that case, one UE acts as co-located 
SC+MSAS as described in clauses 10.3.2 and A.13.2.3. 

The Sync' reference point is used to report synchronization correlation information on the synchronicity relationship 
between the incoming media stream (which could be received by some SCs) and the outgoing media stream(s) (which 
could be received by other SCs) from the SC to the MS AS. The Sync' reference point uses RTCP. 

4.3.9.1 MSAS 

The MSAS is a functional entity that coordinates session synchronization with SCs and SCs for inter-destination 
synchronization purposes. The MSAS session-level capabilities are reflected as elementary functions of the CFIA, its 
media-level capabilities are reflected as independent functional entities or as adjunct functions other functional entities. 
For synchronisation using a direct communication channel between multiple UEs, the MSAS is co-located with the SC 
in a UE. Tasks of the MSAS are: 

• setting up and accepting synchronization sessions with/from SCs; 

• collecting synchronization status information from SCs; 

• collecting synchronization correlation information from SCs; 

• calculating delay information and derive synchronization settings instructions for the SCs and distributing 
synchronization settings instructions to SCs. 

4.3.9.2 SC 

The SC is a functional entity that coordinates session synchronization with the MSAS for inter-destination 
synchronization purposes. It is an elementary function of the UE or an adjunct function of the Transport Processing 
Functions. Tasks of the SC are: 

• setting up and accepting synchronization sessions with/from the MSAS; 

• sending synchronization status information to the MSAS; 

• receiving delay information in the form of synchronization settings instructions from the MSAS; 

• delaying (buffering) a media stream according to the received synchronization settings instruction. 
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4.3.9.3 



sc 



The sc is a functional entity that assists session synchronization by the MSAS for inter-destination media 
synchronization purposes. It is an elementary or adjunct function of functional entities that modify and/or re-originate 
media streams, e.g. a transcoder or a mixer in an MDF. 

4.3.10 Service Protection and Content Protection function (SCP) 

The functional entities and elementary functions that in the NGN integrated IPTV subsystem responsible for Service 
protection and content protection are defined in TS 182 028 [4] clause 7 and TISPAN NGN security architecture 
TS 187 003 [i.l7] in clause 9 and IPTV security TR 187 013 [i.l]. 

4.4 Compliance 

Compliance for the Integrated IPTV service conforms to table la. 

Table 1a: IPTV services and features supported by NGN integrated IPTV subsystem: 



NGN IPTV Release 
Service and Feature 


Short name 
(ServiceType) 


TISPAN R3 Stage 2 
NGN integrated 
IPTV subsystem 


TISPAN R3 Stage 3 
NGN integrated 
IPTV subsystem 


Specification 




TS 182 028 [4] 


Present document 


Linear/Broadcast TV 


BTV 


M 


M 


Linear/Broadcast TV with Trick Play 


BTVwTP 


M 


M 


Time Shifted TV 


TsTV 








Content on Demand 


CoD 


M 


M 


Push CoD 


pCoD 


M 


M 


Near COD 


nCoD 


M 


M 


Network PVR 


nPVR 


M 


M 


Client PVR 


cPVR 








Audio 


Audio 


M 


M 


Pay-Per-View 


PPV 


M 


M 


Interactive TV 


iTV 


M 


M 


Service discovery 


Sdisc 


M 


M 


Service Information (EPG) 


EPG 


M 


M 


Parental Control 


ParCont 


M 


M 


User Profiling & personalization 


UserProf 








Communications and Messaging 


msg 








Notifications 


notif 








IPTV Presence 


presence 








Interaction between users 


iuser 








Interaction with NGN services 


INGN 








Advertising 


AD 


M 


M 


Targeted Advertising 


TAI 








User Generated Content 


UGC 








Internationalization 


Intern 








Content recommendation 


CR 








Games 


Games 








Picture 


Pict 








Bookmarks (Content Marking) 


CB 








Personalized channel 


PCh 








Personalized Service Composition 


PSC 








Service Portability 


SerPort 








Service Continuation between IPTV 
UEs 


ServCont 









ETSI 



21 



ETSI TS 183 064 V3.4.1 (2011-02) 



NGN IPTV Release 
Service and Feature 


Short name 
(ServiceType) 


TISPAN R3 Stage 2 
NGN integrated 
IPTV subsystem 


TISPAN R3 Stage 3 
NGN integrated 
IPTV subsystem 


Service Continuation fixed-mobile 


ServCont 








Remote Control of IPTV services 


RemContr 








Emergency Information 


Emergency 








Interaction with 3"^^ Party application 
(e.g. Parlay) 


3pty 








Interaction with Internet Services 


IntServ 








Service synchronization 


Synch 








Incoming call management 


CallMng 








NOTE: M - Mandatory, 0- Optional, NA - not available or not specified (out of 
scope in release) in architecture. 





Features that are only used by optional services are optional as well. 



5 Procedures using HTTP for NGN integrated IPTV 

NGN integrated IPTV reference points (Tr, Ct2, Ss, Ss') using http shall follow HTTP/1.1 [9]. 

NOTE: Other protocols such as RTSP may be used on Ct2, Ss and Ss'. 

If URI is supplied as "http:" [40], the receiver and the sender shall conform to HTTP/1.1 [9] and use port specified in 
the URI. When the URI is specified as "https:", the receiver and the sender shall establish a connection using https [41] 
with TLSl.O and SSL3.0, and apply encrypted communication using HTTP/1.1 at the port specified in the URI. If the 
port is not specified in the URI, default port 80 is used for "http:" and 443 for "https". 

URI and URL convention defined in [40] shall be used for access to TISPAN Integrated IPTV services. 

5.1 User Equipment (UE) and Control Functions 

Mechanism used for user interaction between UE and Control Function shall support service personalization and 
multiple user behind UE. Access to personalized IPTV services may required additional user authentication and 
authorization, e.g. PIN for content purchase, access to restricted content. The personalization of IPTV services should 
enable fulfil user personal expectation (provide user preferred content and services) during all steps of service selection 
and service delivery. 

The IPTV personalization requires unique identification of the IPTV user, or of the IPTV Service, with assignments 
made by the IPTV Service. The user identification used user identifiers for NGN subscribers as specified in 
TS 184 002 [49]. Private user identifier shall take the form of an NAI, and shall have the form username@ realm as 
specified in clause 2.1 of RFC 4282 [50]. The user authentication shall follows details specified in clause 5.1.3, 
Procedure for Authentication using HTTP Digest [7]. 

5.1.1 Procedures for SD&S 

Mechanisms used to identify service providers and services in the context of service discovery shall apply conforming 
to TS 102 034 [5], clause 5.2. 

SD&S segments may be encoded with BiM conforming to TS 102 034 [5], clause 5.5. 

5.1.1.1 Push mode 

Push model delivery of BCGs using multicast shall use the DVBSTP protocol for this purpose in alignment with 
clause 4.1.2 of TS 102 034 [5]. 
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5.1.1.2 Pull Mode 



In the pull model of unicast delivery of a DVB SD&S data, the HTTP protocol shall be used conforming to 
TS 102 034 [5], clause 5.4.2. 

In the pull model of unicast container-based delivery of DVB BCG data, the HTTP protocol shall be used conforming 
to TS 102 539 [8], clause 4.1.2.2.2. 

In the pull model of unicast query mechanism of DVB BCG data, the HTTP protocol is used to transport SOAP 
messages. This shall be conforming to TS 102 539 [8], clause 4.2. 

NOTE: Some services such as network PVR, notification may fall outside current [5] SD&S scope. In this case 
and for additional services the following mechanism may be used: 

■ The http request may contain other header fields conforming to the [9] and XML records specifying 
additional service name in the XML format. 

■ The response to the HTTP requests above shall contain matching XML service definition records 
or http URL of other SD&S server where this information can be discovered via alternative means. 

The additional XML definitions may be discarded by the UE. 

5.1 .2 Procedure for Service Configuration 

One of the following options should be supported: 

• An Application Server may implement the role of an XCAP server as described in [15] with standard 
authentication mechanisms as discussed below. 

• Standalone XDMS server may be used, in which case Tr interface is re-used between UE and the server. 
XCAP usage shall comply with [15]. 

• Service can be configured over standard http [9]. In this case UE normally implements WEB browser with 
JavaScript or higher support for running WEB applications. 

5. 1 .3 Procedure for Authentication 

HTTP Digest [7] is recommended on the Tr interface. 

MD5 is recommended digest algorithm as defined in [19], MD5 Message Digest Algorithm. 

5.1 .4 Procedure for Customer Facing IPTV Applications 

Application interface is based on http protocol between UE (converged) and ASF (Customer Facing IPTV applications). 

UE should implement an http [9] compliant web browser with JavaScript support. Special requirement for CSS is to 
support to enable rendering capabilities. 

A particular implementation of the Web Browser is outside the scope of the present document, however, most of widely 
used browsers can be supported. 

Application Gateway may be used on the Tr interface; however, the gateway specification is outside the scope of the 
present document. 

Interface between UE and CFIA may use https if additional protection is required. 

If HTTP is used, the UE shall requested IPTV service using HTTP GET or POST methods towards CFIA and supply 
ServiceType for selected IPTV services. 
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The ServiceType HTTP parameter is conveyed as an URI parameter and shall use the following format: 

• "http:" "//" host [ ":" port ] "/etsi/iptv/service?ServiceType=" ServiceType 

• http://iptv.domain.com: 80/etsi/iptv/service?ServiceType=CB 

The HTTP Accept header shall include the content-type identifier that corresponds to the MIME type of XML 
documents representing service parameters: "application/vnd.etsi.iptvservice+xml". 

Table 1b: Customer facing IPTV services, their service types and XML schemas 



IPTV Service 


ServiceType 


Clause where 
procedure 
described 


XML schema 


Notification 


notif 


5.1.5 


Annex C.I 


IVIessaging 


msg 


5.1.6 


Annex C.I 


Presence information 


presence 


5.1.7 


Annex C.I 


Targeted Advertising 


tai 


5.1.8 


Annex H 


User Generated Content 


ugc 


5.1.9 


Annex G (content description) 
Annex C (notification) 


Content Recommendation 


cr 


5.1.10 


Annex C.I 


Content Bookmarks 


cb 


5.1.11 


Annex F.I (XML schema for 
content bookmarks) 


Interactive TV 


itv 


5.1.12 


N/A 


Interaction between users 


iuser 


5.1.13 


C.I 


Interaction with 3'"^ Party 
application (e.g. Parlay) and 
Internet services 


3pty 


5.1.14 


N/A 


Client PVR 


cpvr 


5.1.15 


N/A 


Personalized Channel 


pch 


5.1.17 


Annex 1 (XML schema for 
Content Playlist) 


Service continuation 


sc 


5.1.18 


Annex F.I (XML schema for 
content bookmarks) 



5. 1 .5 Procedure for Notifications 

The UE may receive notifications from the CFIA using Tr interface between the UE (converged) and IPTV ASF 
(Customer Facing IPTV appHcations) via HTTP protocol [9] and either present notification on GUI (Graphical User 
Interface) or initiate service action or both. 

The IPTV ASF (CFIA) shall support XML notifications over HTTP [9] via Tr reference point. Procedure for IPTV 
Notification shall follow signalling flows described in clause B.8. 

5. 1 .6 Procedure for Messaging 

The UE may initiate and present received messages via CFIA using Tr interface between UE (converged) and ASF 
(Customer Facing IPTV applications) via HTTP protocol [9] . 

The UE may initiate and present received messages through interactions with the Common NGN ASF as described in 
TS 182 028 [4], annex A. 

5.1 .7 Procedure for presence information 

The UE may receive presence information via CFIA on Tr interface via HTTP protocol [9]. 

The CFIA may use the Presence User Agent (PUA) as described in [12] and [13]. 

Alternatively, presence Network Agent as described in [13] may be used for IPTV in the Common NGN ASF as a 
gateway to the NGN Presence Server (PS). The Presence Server or agent can be located in the network. 

The PUA can request resource lists from a Resource List Server (RLS) as described in [14] to retrieve presence 
information from multiple users. 
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The PUA (or presence network agent if used alternatively) should provide the mapping of IPTV user account to IMS 
user identities. 

UE may inform CFIA about presence status information. 

Alternatively presence information may be collected by the PUA or network agent (in Common NGN ASF) and 
reported to the NGN presence server. 

5. 1 .8 Procedure for Targeted Advertising 

NGN Integrated IPTV advertising procedure shall follow procedure for targeted ad insertion, interactive ad insertion 
and regionalised ad insertion defined in clause 1 1.10 [4]. 

NGN Integrated IPTV uses XML schema carried over HTTP on Adx and Ady interfaces, which are defined in annex H 
"SCTE based targeted advertising architecture" of [4]: 

• Adx used to exchange advertising related messages between an ADM in the TISPAN CFIA and an SCTE- 130 
functional entities: ADS, POIS and SIS. XML schema carried over HTTP shall apply conforming to 
SCTE130-3 [i.l3]. 

• Ady used to exchange advertising related messages between TISPAN IPTV MF and an SCTE- 130 ADS for 
unicast and broadcast services. The MF entity is interconnected with the Ad Decision service via Ady to made 
ad-selection and ad-placement requests for both broadcast and unicast (e.g. for interstitial, pause opportunities) 
services. XML schema carried over HTTP shall apply conforming to SCTE 130-3 [i.l3]. 

5.1 .9 Procedure for User Generated Content 

The UGC procedures consist of two main phases: UGC creation and watching UGC. 

The UGC creation procedure comprises four steps as described in [4]. Http is used between UE and CFIA over Tr 
reference point: 

• Step 1 : Declaration of User Generated Content. 

• Step 2: Description of User Generated Content information by the UE. 

• Step 3: Creation of User Generated Content. 

• Step 4: Publication of User Generated Content information by the CFIA. 

In step 1 UE sends a User Generated Content creation request to the CFIA and receives a content ID from the CFIA 
using XML schema over HTTP. The content ID is location independent and globally unique. 

In step 2 UE sends a request to the CFIA containing XML description of the User Generated Content: name, type, 
restriction, textual description, special group and others. The XML schema for content description is provided in 
annex G. 

In step 3 the UE requests CFIA via Tr to post User Generated Content either directly via HTTP or upload/upstream in 
unicast to the MF. In case the UGC is upstreamed to the MF the HTTP request contains a SDP or XML session 
description of the media, see [5]. If the content is distributed to the MF, the MF confirms to the CFIA the location at 
which the UGC becomes available. The CFIA keeps the link between UGC content ID, UGC description and optionally 
the MF. 

When user generated content is uploaded using HTTP method PUT shall be used. 

When user generated content is upstreamed, HTTP PUT or HTTP streaming shall be used. 

NOTE 1 : The speed at which content is transmitted with HTTP is limited by the available bandwidth. In the case of 
HTTP PUT, the difference between uploading and upstreaming lies in setting the bitrate for upstreaming 
such that the available bandwidth is equal or higher than the encoding bitrate. This allows for delivery of 
the file in real-time. In the case of HTTP streaming, content that is transported without storing or very 
limited buffering, similar to CoD streaming. 

NOTE 2: XMLHttpRequest can be used for asynchronous signalling of the content. 
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In step 4 CFIA publishes this UGC description to the SD&S to make it available to subscribed UEs. CFIA may use 
existing notification mechanism to announce new UGC content to interested UEs (following http procedures defined in 
clause 5.1.5). The UGC description publication by the CFIA in step 4 may take place before, during or after the UGC 
content creation in step 3. 

After UGC publication a UE can select UGC by browsing SD&S and initiate watching of User Generated Content, or 
pre-select UGC by subscribing to UGC that has already been declared and published, but not yet created. These 
procedures allow a user to select and watch User Generated Content where initiation and delivery of UGC content shall 
used existing procedures (clause 6.1) for CoD, BC or PushCoD services. 

When a UE pre-selects UGC that has already been declared and published, but not yet created, the UE is notified by the 
CFIA when the UGC becomes available, using the existing notification procedure from clause 5.1.5. The notification 
follows the XML schema of annex C, where tIPTVNotificationActionType has the value "UGC_preselection" and 
tIPTVNotificationDescription contains the UGC Contentid that the UE subscribed to. The notification triggers the UE 
to initiate UGC retrieval using existing procedures (clauses 6.1.2 and 6.1.6), at which the MF associates the upstream 
multimedia stream (this clause, step 3) with the downstream multimedia stream (clauses 6.1.2 and 6.1.6). 

5.1.10 Procedure for Content Recommendation 

The Content and service Recommendations ervice (CRS) is used for providing recommendations to IPTV users or user 
groups. The recommendation service may make recommendations to user/groups based on different criteria including 
user profile, user indicated preferences, current viewing habits, historic user activities as defined in [4]. 

The recommendation may be in form of text message (notification), multimedia message, content bookmark (pointer to 
recommended content) or video recommendation streamed from MDF. 

The CRS service procedures include aggregation and correlation of metadata/information for recommendations as 
described in clause 1 1.9 in [4]. User profiling mechanism may be used for collecting and evaluation of user preferences 
(self settings of user interest), user data (service history, presence information, content bookmarks) and actual service 
state to provide support for correctly targeted Content Recommendation. 

CFIA may request content recommendation either based on UE actions or on trigger from external CRS. CFIA should 
deliver content recommendations via existing http notification mechanisms. 

If user accepts recommendation, the UE shall request delivery of recommended content using existing procedures for 
particular content type (e.g. CoD, BC, UGC, PushCoD, etc.) or generate content bookmark for later delivery request. 

5.1 .1 1 Procedure for Content Bookmarks 

An IPTV Content Bookmark service consists of two main steps: 



• 



• 



Creation of IPTV Content Bookmark: allows a user to create and store configurable pointers to content, 
e.g. entire or parts of content (favourite scene) to be able to quickly access the specified content and location. 

Retrieval of IPTV Content Bookmark: allows to access directly content or exchange and share data about 
user's favourite IPTV content. 



Creation and retrieval shall use HTTP over Tr interface between UE and CFIA. 

Content Bookmarks should be stored in User Profile. User may enable sharing of bookmarks, in which case CFIA may 
update SD&S with bookmarks metadata. 

Content Bookmark shall used XML schema from annex F. 

Procedure for Content Bookmarks may be adopted by other services and procedures to identify point and share pointer 
to exact content (from defined time as entire or part of the content) as for example: 

• Service continuation. 

• Content recommendation. 
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• User interaction. 

• Interactive TV. 

• Notification (about content or specific part of content). 

Content Bookmark primary purpose is to set a personal user bookmark (which will be used by user or send to other 
users for sharing the bookmark), but same content bookmark mechanisms should be used as well by IPTV system itself 
pointing out the content or to refer to timestamp in content (following structure of XML schema in annex F). CFIA 
should control the use and authorization for any of the mentioned content bookmark. 

For some services may be Content Bookmark linked with content metadata (e.g. service selection information) and/or 
content description (as in annex G). 

5.1 .12 Procedure for Interactive TV 

CFIA shall provide the UE with the selection of Interactive IPTV applications. After selection of Interactive IPTV 
application (e.g. as for example one from listed in clause 11.19 Interactive TV procedures [4]), the UE sends HTTP 
request to CFIA via Tr reference point to initiate selected Interactive TV application. The selected application can either 
be located with CFIA, or externally, in which case the UE shall be provided with URL of External Interactive IPTV 
application (clause 5.1.14). 

The UE should implement an HTTP [9] compliant web browser with JavaScript support. Special requirement for CSS is 
to support to enable rendering capabilities and adopted for presentation on TV. 

NOTE: A particular implementation of the Web Browser is outside the scope of the present document; however, 
most of widely used browsers can be supported. 

CFIA should act as HTTP proxy or redirect UE to external ASFs. 

5.1 .13 Procedure for Interaction between users 

The UE may initiate and received interaction messages between two or among multiple UEs via CFIA using Tr 
interface between UEs and ASF (Customer Facing IPTV applications) via HTTP protocol [9] . 

The interaction between UEs may contain HTTP messages with attached XML as described in clause A.5.1. 

5.1 .14 Procedure for Interaction with 3'^ Party application (e.g. Parlay) and 
Internet services 

Same procedure as described in clause 5.1.12 shall apply for Interaction with 3^^ Party application or external Internet 
services. 

If Parlay/Parlay X is used, OS A Parlay/Parlay X gateway for interaction with OS A S (as described in [4], clause A.l) 
shall be provided. 



5.1 .15 Procedures for Client PVR (UE) 



In order to provide Client PVR (c-PVR) service, the UE initially select required content from EPG/BCG via customer 
facing IPTV application and requests scheduling selected content for recording in the UE. 

Before the recording start, CFIA shall send notification to the UE based on clause 5.1.5, Procedure for Notifications, to 
initiate scheduled recordings (when UE is online). 

The application of IGMP protocol between UE and TPF for content delivery shall comply with EC procedure 
(clause 7.1.1 Procedure for BTV service). After the UE joins multicast channel, it shall start recording the content as 
Client PVR stored on the UE storage. Watching of recordings is performed locally in the UE and no further interaction 
with CFIA or SD&S is required. 
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5.1 .16 Procedure for initiation of inter-destination media synchronization 

5.1.16.1 Synchronization Client (SC) 

Upon a request for inter-destination media synchronization, the SC shall send an HTTP GET request to the MS AS. 

NOTE 1 : There are various ways to convey which services require inter-destination media synchronization. This 
can be signalled via SD&S information (e.g. the BCG/EPG/ESG), through a shared service control 
session, with notifications, recommendations and others. 

The SC shall include the SyncGroupId as part of HTTP GET request. If the SyncGroupId is known, it shall be set 
accordingly. If no SyncGroupId is known, e.g. because the SC is first to setup the inter-destination media 
synchronization, the SC shall include the parameter but leave it empty. 

The SyncGroupId HTTP parameter is conveyed as an URI parameter and shall use the following format: 

• "http:" "//" host [ ":" port ] "/etsi/sync/syncgroup?SyncGroupId=" SyncGroupId 

SyncGroupId is a 32-bit unsigned integer in network byte order and represented in decimal. The value SyncGroupId=0 
represents an empty SyncGroupId. The value 4294967295 (2^32-1) is reserved for future use. The following URI shows 
an example of a reference to a sync group: 

• http://iptv.example.com:80/etsi/sync/syncgroup?SyncGroupId=1073774600 

The HTTP Accept header shall include the content-type identifier that corresponds to the MIME type of XML 
documents representing synchronization parameters: "application/vnd.etsi.iptvsync+xml". 

If the SC is mapped on the UE, then the SyncGroupId parameter may be contained in the HTTP GET request for 
service initialisation, see also TS 182 028 [4], clauses 6.2.1 and 6.2.2. 

NOTE 2: The ways that an SC can obtain a SyncGroupId are similar to obtaining a phone conference id. For 

example, one user can request a new SyncGroupId through an off-line process, and share it with other 
users through an offline process. If the group of users does already have a group identifier, e.g. a phone 
conference id, they may reuse this identifier. 

When the SC receives an HTTP 200 OK response, the SC shall be able to deal with the following parameters, as 
described in clause 5.1.16.2: 

• ssrc-id; 

• rtcp-port: IP address plus port number; 

• SyncGroupId. 

The parameters are part of the XML pay load in the HTTP response; see annex E for XML schema. 

The SC shall keep these values for use in synchronization status information and settings instructions procedures, 
described in clause 10.3. Since the SSRC value may change if an SSRC conflict is discovered at the transport level, the 
SC shall be prepared for this. 

When leaving a synchronization group, the SC shall send an HTTP DELETE request to the MS AS. The SC shall 
include the SyncGroupId as part of HTTP DELETE request. 

5.1 .1 6.2 Media Synchronization Application Server (MSAS) 

Upon receiving an HTTP GET request, the (session-level) MSAS shall be able to deal with the following parameter. 

• SyncGroupId. 

The SyncGroupId is received as an URI parameter, see clause 5.1.16.1. If the MSAS cannot retrieve a SyncGroupId 
parameter from the HTTP message, no further procedures apply. 
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The MS AS shall assign a media-level MS AS using the SyncGroupId. If the SyncGroupId is present and empty 
(SyncGroupId=0), the MSAS shall assign a new SyncGroupId to the synchronization session and it shall assign a 
media-level MSAS address and port to be used for this SyncGroupId. If the SyncGroupId is present and is assigned a 
value, the MSAS shall check if this value is known. If this value is known, the MSAS shall lookup the media-level 
MSAS address and port to be used for this synchronization group. If this value is not known, the MSAS shall assign an 
MSAS address and port to be used. If the SyncGroupId is empty, the MSAS shall store this SyncGroupId and assign a 
media-level MSAS address and port to be used for this SyncGroupId. 

NOTE 1 : The MSAS can assign address and port values from a different media-level MS AesS if necessary. 

The MSAS shall include in its HTTP 200 OK response to the SC the following parameters: 

• ssrc-id; 

• rtcp-port: IP address plus port number; 

• SyncGroupId. 

The parameters are encoded in XML using the XML schema defined in annex E. The ssrc-id is a 32-bit unsigned 
integer in network byte order and represented in decimal. The SyncGroupId is a 32-bit unsigned integer in network byte 
order and represented in decimal. The Content-Type header shall be set to the MIME type 
"application/vnd.etsi.iptvsync+xml". 

If the MSAS is mapped on the CFIA, then the sync interface maps on the Tr interface, and these parameters may be 
contained in the HTTP 200 OK response for service initialisation, see also TS 182 028 [4], clauses 6.2.1 and 6.2.2. 

NOTE 2: In case of a BTV service, in order to distinguish RTCP reports coming from the media-level MSAS and 
from the multicast media source, they can have different addresses. 

Upon receiving an HTTP DELETE request, the MSAS shall respond with a 200 OK message. 

5.1.17 Procedures for Personalized Channel (UE) 

Personalized Channel (PCh) service allows user to define and watch one or multiple pre-configured/scheduled content 
items as a single (virtual) channel in timeline as user schedule on UE via Tr interface using HTTP protocol. 

UE shall construct Personalized Channel playlist follow XML schema specified in annex I (XML schema for Content 
PlayHst). 

5.1.18 Service continuation 

This clause discusses procedures for service continuation. 

5.1 .18.1 Procedure for service continuation using Content Bookmarks 

As described in [4] in clause 1 1.12 service continuation should be provided between two NGN IPTV UEs. 
The procedure is applicable for the following services: 

Trick modes on broadcast TV. 

Content on Demand. 

- Time-shift TV. 

- Network PVR. 
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Service continuation contains two phases - pause and restart (sometime refer also as park and pick-up) where Content 
Bookmark procedures (from clause 5.1.11) should be reused in following way: 

• Pause for service continuation shall pausing actually watched content and creation of IPTV Content Bookmark 
with pointers to content (CoD, recorded as nPVR/Time-shift/BCwTM) and timepoint. 

• Restart of paused service then shall in second phase continue on bookmarked content and timestamp. 

Creation and retrieval shall use HTTP over Tr interface between UE and CFIA (Content Bookmark itself is based on the 
schema from annex F). 

Content Bookmarks should be stored in User Profile. 



6 Procedures using RTSP for NGN integrated IPTV 

The Real Time Streaming Protocol [6], or RTSP, is an application-level protocol for control over the delivery of data 
with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of 
real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. 

This clause defines usage of RTSP in dedicated IPTV for interactive control between UE and IPTV service control 
functions: IPTV-C and MCE. 

RTSP application for interactive service control over IP multimedia delivery is defined in DVB-IPI [5] and unless stated 
explicitly otherwise, the application defined in DVB-IPI [5] is used. 

Service selection 

The service discovery and selection process as defined in clause 5 provides UE with the RTSP URL for initializing 
interactive multimedia delivery session. The URL discovery methods are discussed in clause 6.1.1 of [5]. 

The format of RTSP URL shall comply with [7]. 

Session transport 

A transient TCP connection is a temporary connection that exists only long enough to transmit one or more requests. 

The UE should use transient connection for exchanging control messages on Ct2 interface for selecting most suitable 
MCE function. After MCE is selected there is no need to keep the connection. 

A persistent TCP connection is a lasting connection between a client and RTSP server, all requests and replies are sent 
over the same connection, and the connection remains intact until the session is completed. The UE should use 
persistent connection for RTSP control over interactive media delivery on Xc interface. The usage of persistent 
connection is discussed in clause 6.1.2 of [5]. 

Optionally, transient connection can be used on Xc interface. 

A method to keep a persistent connection active is discussed in clause 6.1. 

Security considerations 

Security considerations discussed in clause 6.1.4 of [5] apply. 

Optionally HTTP Digest Access Authentication can be applied to RTSP control messages as defined in [7]. 
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Mapping between DVB and TISPAN profiles 

The services defined in the service level requirements and NGN integrated IPTV architecture is identical when mapped 
to DVB service profiles as defined in table 2. 

Table 2: Mapping between TISPAN IPTV services and DVB service profiles 



TISPAN Service 


DVB Service profile 


BTV 


LMB 


BTV with trick modes 


MBwTM 


CoD 


CoD 


Time-shift TV 


CoD 


Network PVR 


CoD 



RTSP Methods 

RTSP methods supported for each profiles and their definitions are identical to clause 6.3 [5]. 

The requirement to support XML structures in clause 6.3 of [5] is optional. SDP parameters can be used instead. 

RTSP Headers 

The pause trick mode operation may be signalled by the standard RTSP PAUSE message as defined in [6]. 

RTSP scale header with value is optional. 

6.1 User Equipment (UE) and Control Functions 

6.1 .1 Procedure for BTV service 

Usage of RTSP protocol for normal broadcast services without trick modes is not defined in the present document. 

6.1 .2 Procedure for CoD service 

NGN integrated IPTV uses RTSP protocol [6] for control over the delivery of multimedia with real-time properties. 
Usage should be compliant with TS 102 034 [5] unless specified otherwise. 
Table 3 illustrates RTSP methods in [6], [5] and NGN integrated IPTV. 
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Table 3: RTSP methods in [6], [5] and NGN integrated IPTV 



RTSP Method 


Direction: 
C = client - 

UE; 
S = Server - 

iUICF 


RFC 2326 [6] 


DVB Requirement 
TS 102 034 [5] 


TiSPAN 
NGN integrated iPTV 








LIUIB 


iUIBwTIUI 
and CoD 


Coupied 
mode 


Decoupled 
mode 


ANNOUNCE 


C^S 


MAY 


MAY 


MAY 


MAY 


MAY 


ANNOUNCE 


S->C 


MAY 


SHOULD 


SHOULD 


SHOULD 


SHOULD 


DESCRIBE 


C^S 


SHOULD 


SHOULD 


SHOULD 


SHOULD 


SHOULD 


GET_PARAMETER 


C->S 


MAY 


SHOULD 


SHOULD 


SHOULD 


SHOULD 


GET_PARAMETER 


S^C 


MAY 


MAY 


MAY 


MAY 


MAY 


OPTIONS 


C->S 


SHALL 


SHALL 


SHALL 


SHOULD 


SHOULD 


OPTIONS 


S^C 


MAY 


MAY 


MAY 


MAY 


MAY 


PAUSE 


c^s 


SHOULD 


N.A. 


SHALL 


SHALL 


SHALL 


PLAY 


c^s 


SHALL 


SHALL 


SHALL 


SHALL 


SHALL 


REDIRECT 


s^c 


MAY 


SHALL 


SHALL 


N.A. 


SHALL 


SETUP 


c^s 


SHALL 


SHALL 


SHALL 


SHALL 


SHALL 


TEARDOWN 


c^s 


SHALL 


SHALL 


SHALL 


SHALL 


SHALL 


SET_PARAMETER 


c^s 


MAY 


N.A. 


N.A. 


N.A. 


N.A. 


SET_PARAMETER 


s^c 


MAY 


N.A. 


N.A. 


N.A. 


N.A. 


RECORD 


c^s 


MAY 


N.A. 


N.A. 


N.A. 


N.A. 


NOTE 1 : N.A. - Not Applicable. The text in bold shows optional difference in the required support of 

RTSP methods in NGN integrated IPTV and TS 102 034 [5]. 
NOTE 2: ANNOUNCE, DESCRIBE, OPTIONS are optional methods which are not shown explicitly on 

the NGN integrated IPTV flows, but may be supported by UE and IVICF. 



Coupled mode: In the coupled mode Customer facing IPTV applications reserves the delivery resources via IPTV 
Control on Ss interface and returns the UE RTSP URL with the exact location of the MCF to request interactive media 
delivery. The format of RTSP URL shall comply with [6] . 

The UE in the coupled mode shall send RTSP SETUP message containing at minimum RTSP URL, Sequence, and 
Transport headers to establish video delivery. Sample message flow in the coupled mode is shown in table 4. 

Table 4: Sample RTSP message flow in coupled mode 



RTSP iUletliod 
from UE 


RTSP iUlethiod 
toUE 


Reference 
point 


Notes 


SETUP 




Xc 


UE requested on-demand session from MCF 




RTSP 200 OK 


Xc 




PLAY 




Xc 


UE requested the play-out to start 




RTSP 200 OK 


Xc 




GET PARAMETER 




Xc 


UE sends heartbeat to keep the session active 




RTSP 200 OK 


Xc 




PAUSE 




Xc 


UE initiated trick mode 




RTSP 200 OK 


Xc 






ANNOUNCE 


Xc 


MCF made asynchronously announcement to the UE, 
e.g. "End of stream reached" 


RTSP 200 OK 




Xc 




TEARDOWN 




Xc 


UE closed on-demand session 




RTSP 200 OK 


Xc 





Decoupled mode: In the decoupled mode Customer facing IPTV applications return the UE RTSP URL with the exact 
location of the IPTV control. Resource reservation, selection of the exact MCF and session recovery is done via IPTV 
control at the time when the delivery is requested. 

The UE in the decoupled mode shall send RTSP SETUP message containing at minimum RTSP URL, Sequence, and 
Transport headers to establish video delivery. Sample message flow in the decoupled mode is shown in table 5. 
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Table 5: Sample RTSP message flow in decoupled mode 



RTSP method 
from UE 


RTSP method 
toUE 


Reference 
point 


Notes 


SETUP 




Ct2 


UE requested on-demand session from IPTV control 




REDIRECT 


Ct2 


IPTV Control nominates MCF and reserves delivery 
resources 


SETUP 




Xc 


UE requested on-demand session from MCF 




RTSP 200 OK 


Xc 




PLAY 




Xc 


UE requested the play-out to start 




RTSP 200 OK 


Xc 




GET PARAMETER 




Xc 


UE sends heartbeat to keep the session active 




RTSP 200 OK 


Xc 




PAUSE 




Xc 


UE initiated trick mode 




RTSP 200 OK 


Xc 






ANNOUNCE 


Xc 


MCF made asynchronously announcement to the UE, 
e.g. "End of stream reached" 


RTSP 200 OK 




Xc 




TEARDOWN 




Xc 


UE closed on-demand session 




RTSP 200 OK 


Xc 





Decoupled mode can be used for on-demand session recovery in the real-time, e.g. due to MCF failure. The UE upon 
detection loss of stream repeats session initiation sequence from table 3, supplying the last position of the received 
video in the "Range" header of the first PLAY method. The newly allocated MDF continues media delivery from the 
interrupted position instead of the beginning. If the UE contains sufficient buffering, multimedia session is recovered 
without visible artefacts. 

Using both transient and persistent connection the UE should keep the session active by sending heartbeats in the form 
of RTSP GET_PARAMETER method at the negotiated time inter RTSP. This method is applicable to any control 
session during CoD, BTV with trick modes, time-shift TV and nPVR. 

6.1 .3 Procedure for BTV with trick modes service 

NGN integrated IPTV media broadcast with trick modes session is a service level aggregation of broadcast and 
on-demand sessions. Combined session flow is shown in clause 11.3 of [4]. 

Before starting the service, the UE shall request from the Customer facing IPTV applications RTSP URL from where 
the interactive media delivery can be requested using RTSP protocol. 

The service is started by joining broadcast channel as specified in clause 7. The UE can pause the stream by leaving the 
broadcast stream as discussed and clause 7 and optionally setup interactive media delivery using identical procedure to 
the COD service, clause 6.1.2. 

Both coupled and decoupled modes can be supported. 

In the coupled mode Customer Facing IPTV application nominates a particular MCF for on-demand media delivery. 

In the decoupled mode the selection is performed in the real-time during switch to the trick mode. 

Sample message flow for BTV with trick modes in the decoupled mode is shown in table 6. 
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Table 6: Sample message flow for BTV with trick modes in the decoupled mode 



from UE 


toUE 


Reference 
point 


Notes 


IGMPJOIN 




Xd (Dj, Dl or Ds) 


UE requested to join broadcast channel. 
The Access and Core network performs local 
admission control. Multicast channel is delivered 


IGMP LEAVE 




Xd (Dj, Dl or Ds) 


UE requested trick mode. UE leaves multicast 
channel 


RTSP SETUP 




Ct2 


UE requested on-demand session from IPTV 
control 




RTSP 
REDIRECT 


Ct2 


IPTV Control nominates MCF and optionally 
reserves delivery resources (previously reserved 
resources can be re-used) 


RTSP PLAY 




Xc 


UE requested the play-out to start 


TRICK MODE control on Xc 


TEARDOWN 




Xc 


UE switches from trick mode 




RTSP 200 OK 


Xc 






ANNOUNCE 


Xc 


MCF made asynchronously announcement to the 
UE, e.g. "End of stream reached" 


RTSP 200 OK 




Xc 




IGMPJOIN 




Xd (Dj, Dl or Ds) 


UE switches back to life stream. 
The Access and Core network optionally performs 
local admission control, (previously reserved 
resources can be re-used) 



6. 1 .4 Procedure for time-shift TV 

In order to provide time-shift TV service, MDF records TV programs available on the broadcast channels. The 
programs form a part of EPG (BCG) as discussed in clause 5 and should be requested on Tr interface. 

After selecting time-shifted content from EPG/BCG, the UE requests from the customer facing IPTV applications 
RTSP URL for initializing multimedia delivery time-shifted content. The procedure from this point is identical to CoD 
service defined in clause 6.1.2. 

6.1.5 Procedure for n PVR 

In order to provide nPVR service, the UE initially selected from EPG/BCG via customer facing IPTV application what 
content should be recorded in the MDF as discussed in clause 5. 

When the recording has been initiated, UE can request from the customer facing IPTV applications with the available 
recordings. The application of RTSP protocol for content delivery is identical to CoD procedure. 

NOTE: Both coupled and decoupled modes are supported for nPVR. 

In the coupled mode, client is allocated precise disk quote on a selected MDF. The MCF associated with the MDF is 
always selected for interactive control over nPVR services. 

In decoupled mode, statistical optimizations are possible, e.g. only one or small number of content copies is created and 
users are redetected to the nearest copies via Ct2 interface using RTSP REDIRECT. 

Content delivery's procedure is identical to time-shift TV service, MDF records TV programs available on the broadcast 
channels. The programs form a part of EPG (BCG) as discussed in clause 5 and should be requested on Tr interface. 

6.1 .6 Procedures for Push CoD (UE, IPTV-C) 

Push COD can be initiated by CFIA based on subscription, user profile or defined IPTV service provider offer. When 
CFIA identified event and time to push content to the UE, it shall send notification to the UE as described in 
clause 5.1.5 Procedure for Notifications before uploading or streaming of the content to the UE (procedure described as 
Push content from MDF). 
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Push CoD in case of unicast content delivery shall use unicast RTSP/HTTP based streaming or HTTP based download 
of CoD content. Where Push CoD content is streamed/downloaded from MDF to the UE. The UE stores push CoD 
content for later consumption. 

Push CoD multicast content delivery shall used BC multicast stream or optionally multicast download based on FLUTE 
from MDF via transport processing functions. The UE joins push CoD as BC service without immediate presenting 
content to the user. The UE instead stores push multicast CoD content for later consumption. 

The IPTV system shall support following download session types as described in [5], clause 10: 

• Scheduled Multicast Download (SMD) Session. 

• Carousel Multicast Download (CMD) Session. 

• Unicast Download (UD) Session. 

The UE and MF functions shall support all mandatory features of all three types of download sessions [5]. 

URI of PushCOD content and PushCOD download session descriptions can be provided in XML or in SDP syntax shall 
follow [5], clause 10.3.2). 

6.1 .7 Procedures for inter-destination media synchronization (SC) 

If the SC did not receive the (complete) synchronization information from the CFIA via the procedure in 

clause 5.1.16.1, the SC shall request this information by including the SyncGroupId in the RTSP SET UP message. The 

SyncGroupId may be kept empty (value 0) if the SC does not yet know the SyncGroupId. 

• a=rtcp-xr: grp-sync,sync-group=<SyncGroupId>, as specified in TS 183 063, clause W.2 [17]. 

When receiving the reply to the RTSP SET UP message, the SC shall check its SDP and extract the SSRC, the 
rtcp-parameter containing the MS AS address and the SyncGroupId. 

When an SSRC conflict occurs at the transport level, the SC shall be prepared to receive an RTSP ANNOUNCE 
containing a new SSRC value. 

6.1 .8 Procedures for inter-destination media synchronization 

If the MCE receives an RTSP SET UP message containing a SyncGroupId in the SDP, the MCE shall include the 
following attributes in the SDP it sends to the SC: 

• a=ssrc:<ssrc-id> <attribute>:<value> as specified in [44]; 

• a=rtcp:port [nettype space addrtype space connection-address] as specified in [45]; 

• a=rtcp-xr: grp -sync, sync -group=<value>, as specified in TS 183 063, clause W.2 [17]. 

SyncGroupId is a 32-bit unsigned integer in network byte order and represented in decimal. The value SyncGroupId=0 
represents an empty SyncGroupId. The value 4294967295 (2^32-1) is reserved for future use. 

If an SSRC conflict occurs at the transport level, and the ME has to assign a new SSRC value, the MCE shall send an 
RTSP announce to the SC containing the new SSRC value as part of the modified SDP. 



6.2 IPTV Control (IPTV-C) 



6.2.1 Procedure for BTV service 

Usage of RTSP protocol for normal broadcast services without trick modes is not defined in the present document. 
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6.2.2 Procedure for CoD service 

IPTV Control upon receiving SETUP message from the UE on Ct2 interface, responds with the RTSP REDIRECT 
message containing at minimum sequence and location header. 

The location of the nominated MCE is passed in the location header. The header should comply with [6]: 

• "Location: rtsp://host:port"; 

• "host = <A legal Internet host domain name of IP address (in dotted decimal form), as defined by [6], 
clause 3.2 >"; 

• "port=*DIGIT". 

7 Procedures using IGMP for NGN integrated -IPTV 

During SD&S process the UE shall discover multicast address to access broadcast IPTV services, e.g. BTV, BTV with 
trick mode. 

Broadcast IPTV services are based upon using multicast delivery and signalling as defined in the Internet Group 
Management Protocol [20]. The IGMP is applicable on the Xd interface. 

Xd interface can be subdivided into Dj, Di and Ds [4]. UE should use IGMP on the Dj interface. If the multicast stream 
is not available at the access network, the access network will propagate IGMP messages on the Di interface. 

7.1 User Equipment (UE) 

If Ipv4 is used for the transport, the UE shall support IGMP v3 as described in [20] . 

If Ipv6 is used for the transport, the UE shall support MLDv2 as described in [21]. 

Backward compatibility rules between the UE and the Transport Function have to be done conforming [20], clause 7 
and [21], clause 8. 

7.1.1 Procedure for BTV service 

The IGMP protocol shall be used conforming to [5], clause 7.3.1 for: 

• initiating the BTV service on the discovered multicast address; 

• leaving the BTV service. 

7.1 .1 .1 Procedure for starting to receive multicast 

In order to start receiving multicast media stream, the UE is required to join a multicast group. 

The UE shall send a Membership Report Message (IGMP) or Multicast Listener Report Message (MLD) for joining in 
a multicast group. 

The message shall be populated as follows: 

• Multicast Address field is set to the multicast address to be joined in. 

• Source Address field is set to the source address to include if such information is available to the UE and if the 
protocol version allows it. 
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7.1 .1 .2 Procedure for stopping to receive multicast 

In order to stop receiving multicast media stream, the UE is required to leave the multicast group. 

The UE shall send a Membership Report Message (IGMP) or Multicast Listener Report Message (MLD) for leaving a 
multicast group, if the multicast protocol version allows it. 

The message shall be populated as follows: 

• Multicast Address field is set to the multicast address to be left. 

• Source Address field is set to the source address to exclude if source address had been included during the join 
procedure. 

7.1 .1 .3 Procedure for channel switching 

In order to operate channel switching, the UE is required to leave the old multicast group and join a new multicast 
group. 

The UE shall send a Membership Report Message (IGMP) or Multicast Listener Report Message (MLD) for leaving 
and joining in a multicast group. 

The message shall be populated as explained in clauses 8. LI and 8.L2. 

7.1 .2 Procedure for BTV with trick modes service 

The IGMP protocol shall be used conforming to [5], clause 7.3.1 for: 

• initiating the BTV with trick mode service on the discovered multicast address; 

• switching from unicast mode back to multicast delivery modes during trick mode operations as defined in [4] ; 

• leaving the BTV with trick mode service. 

7.1 .3 Procedures for Near COD (UE, MDF) 

Near COD streams shall be delivered using IP multicast from MDF to transport processing function as described in [4] 
(clause 1L4. Near CoD ) and clause 7. 

The MDF provides a Near CoD service as a set of multicast channels with the same content where start of the same 
content on each channel is shifted in time depending on length of content and size of the smallest seek operation (e.g. an 
interval can be 10 s of minutes). 

NOTE: For example if content duration is 100 minutes and IPTV service provide chooses to start Near CoD each 
15 minutes, it would require at least 7 multicast stream for Near CoD service for a single content item. 

The UE retrieves via Tr interface service selection information about Near COD content from SD&S, e.g. IP addresses 
of associated multicast channels. 

The UE shall initialize BTV service sending a Membership Report Message (IGMP) or Multicast Listener Report 
Message (MLD) for joining in a multicast group (as described in clause 7.1.1.1). 

If trick play is supported by Near COD it should follow procedure for BTV with trick modes service (clause 7.1.2). In 
this case, when fast forward stream reaches the same time position as N+1 multicasted Near COD channel, the UE 
should instead of using unicast switch back to multicast delivery and join N+1 Near CoD channel as defined in [4]. 
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7.2 Transport Functions 



For Ipv4 multicast IPTV service distribution, the network transport functions shall support minimally IGMPv2 or 
higher. The use of IGMPv3 is recommended, in which case the backwards compatibility rules of [20], clause 7 shall 
apply. 

For Ipv6 multicast IPTV service distribution, the network transport functions shall support minimally MLDvl or higher. 
The use of MLDv2 is recommended, in which case the backwards compatibility rules of [21], clause 8 shall apply. 



8 Procedures using SIP for NGN integrated IPTV 

8.1 User Equipment (UE) 
8.1.1 Procedure for Notifications 

SIP is optional on Tr interface between UE and CFIA or NGN Applications. SIP usage should comply with [25]. 

SIP enabled converged IPTV UE may receive notifications through interactions with the Common NGN ASF as 
defined in TS 182 028 [4], annex A. 

The SIP message body may be used as a generic unified notification container when Common NGN ASF terminates 
notifications from multiples incoming sources, i.e. IM (SIP), MMS/SMS (MM7, SMPP), e-mail (SMTP), other for 
delivery to the UE via single mechanism. The SIP message body may optionally contain actions, which user are 
allowed to perform. The user can select action(s), which will be passed back to the Common NGN ASF for processing 
as described in clause A. 9. 

This procedure shall comply with mechanism described in [18] SIP SUBSCRIBE and SIP NOTIFY. 



8. 1 .2 Procedure for Messaging 



If the UE supports SIP protocol, then alternatively text messages may be delivered via SIP MESSAGE format as 
defined in [10]. SIP message body may be used as a generic unified message container. Conmion NGN ASF terminates 
messages from multiples incoming sources, i.e. IMS-IM (SIP), MMS/SMS (MM7, SMPP), e-mail (SMTP), other for 
delivery to the UE via single mechanism. The SIP MESSAGE body may optionally contain actions, which users are 
allowed to perform. The user can select action(s), which will be passed back to the Common NGN ASF for processing 
as described in clause A. 5. 



9 Procedures using DVBSTP for NGN integrated IPTV 

The DVBSTP may be supported by UE and SD&S functional entity. 

9.1 User Equipment (UE) 

9.1.1 Service Discovery and Selection (SD&S) 

9.1 .1 .1 Request of DVB Service Discovery and Selection data 

In the DVB push model of multicast deHvery of DVB SD&S data, the UE shall attach to the multicast DVBSTP 
identified conforming to TS 102 034 [5], clause 5.2. 

9.1 .1 .2 Request of DVB Broadband Content Guide 

In the DVB push model of multicast deHvery of a DVB BCG data, the UE shall attach to the multicast DVBSTP 
streams identified conforming to TS 102 034 [5], clause 5.2. 
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9.2 Service Discovery and Selection (SD&S) 
9.2.1 Procedure for Service Selection 

9.2.1 .1 Delivery of DVB Service Discovery and Selection data 

In the DVB push model of multicast delivery of DVB SD&S data, the DVBSTP protocol shall be used conforming to 
TS 102 034 [5], clause 5.4.1. 

TS 184 009 [26], which specifies the TV URI as globally unique identifier to identify broadcast television channels may 
be used in the mapping of BC service for DVB Technology as follows. The ServiceName attribute of the 
Textualldentifier of TS 102 034 [5], clause C.3.24, should be populated with the TV URI identifying the television 
channel [26]". 

9.2.1 .2 Delivery of DVB Broadband Content Guide 

In the DVB push model of multicast delivery of a DVB BCG data, the DVBSTP protocol shall be used conforming to 
TS 102 539 [8], clause 4.1.2.2.1. 

10 Procedures using RTP/RTCP and UDP for NGN 
integrated IPTV 

10.1 User Equipment (UE) 

10.1 .1 Procedures for Real-Time Transport 
10.1.1.1 Transport using MPEG2TS 

The UE shall be able to receive the content encapsulated into MPEG2TS over RTP conforming to TS 102 034 [5], 
clause 7.1.1. 

The UE shall be able to receive the content encapsulated into MPEG2TS over UDP conforming to TS 102 034 [5], 
clause 7.1.2. 

If VBR is used, the VBR shall be capped and resource reservation performed at the cap rate. In this case fixed length 
GOP is recommended. 

10.1 .2 Procedure for Real-Time Transport Error Correction 

The UE may support a transport error correction mechanism. 

1 0.1 .2.1 Unidirectional Transport Error Correction 

When unidirectional transport error correction is used, the UE shall be able to receive an Application Layer EEC, 
conforming to TS 102 034 [5], annex E. 

If VBR is used, the VBR shall be capped and resource reservation performed at the cap rate. In this case fixed length 
GOP is recommended. 
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10.2 Media Delivery Function (MDF) 

10.2.1 Procedures for Real-Time Transport 
10.2.1.1 Transport using MPEG2TS 

The MDF shall be able to send the content encapsulated into MPEG2-TS as specified in TS 102 034 [5] clause 7.1. 
The MDF shall support: 

• the transport of the IPTV content within MPEG2TS layer over RTF shall be done conforming to 
TS 102 034 [5], clause 7.1.1; 

• the transport of the IPTV content within MPEG2TS layer over UDP shall be done conforming to 
TS 102 034 [5], clause 7.1.2. 

1 0.2.2 Procedure for Real-Time Transport Error Correction 

The MDF may support a transport error correction mechanism. 

1 0.2.2.1 Unidirectional Transport Error Correction 

For unidirectional transport error correction the MDF shall use an application Layer FEC mechanism, conforming to 
annex E in TS 102 034 [5]. 

1 0.2.3 Procedures for inter-destination media synchronization 

The use of inter-destination media synchronization requires the MDF to support transport using MPEG2TS layer over 
RTP, see clause 10.2.1.1. 

1 0.3 Synchronization Client (SC) 
10.3.1 Procedure for real-time transport 

The SC shall support at least one of the following transport technologies: 

• MPEG2TS encapsulation. 

10.3.1.1 Transport using MPEG2TS 

The SC may be able to process content that is encapsulated in MPEG2TS packets. 

When using the MPEG2TS encapsulation technology, the SC shall support MPEG2TS over RTP as described in 
clause 10.1.1.1. 

NOTE: The limitation to MPEG2TS over RTP is necessary since RTCP is used. 

The SC shall support RTCP Extensions for Single-Source Multicast Sessions (i.e. BC services) with Unicast Feedback 
as specified in [28]. 
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1 0.3.2 Procedures for inter-destination media synchronization 

The SC shall send RTCP Receiver Reports (RRs) to media-level MSAS address, which is the specified IP address and 
port number as exchanged during the synchronization initiation or to a pre-configured media-level MSAS address in 
case of mapping the UE on a Transport Processing Function, see clause 4.3.9. 

The SC shall extend the RRs with synchronization status information, using an RTCP extended Report (XR), as 
specified in TS 183 063 [17], clause W.l. The synchronization status information shall include the SSRC of source, the 
Packet Received NTP timestamp and the Packet Received RTP timestamp. It should include the presentation time 
stamp. 

The SC shall populate the Media Stream Correlation Identifier with SyncGroupId parameter as part of the XR as 
specified in TS 183 063 [17], clause W.l. 

The SC shall be able to receive RTCP reports from the MSAS, on the regular RTCP receive port. 

The SC shall be able to receive RTCP extended Reports (XR) containing synchronization settings instructions. As 
specified in TS 183 063 [17], clause W.l. The RTCP XRs with synchronization settings instructions shall include the 
SSRC of source, and packet arrival time information, specifically the reference Packet Received NTP timestamp and 
the reference Packet Received RTP timestamp receipt time stamp. It should include the reference Packet Presented NTP 
timestamp. These RTCP XRs may be both appended to RTCP Sender Reports (SRs), but may also be received 
separately. 

NOTE 1 : Synchronization settings instructions may be interpreted as the synchronization status information of a 
virtual SC to which this SC may try to synchronize. 

The SC shall be NTP synchronized [48]. 

NOTE 2: The quality of the underlying NTP synchronization of SCs is a determining factor in inter-destination 
media synchronization. ITU-T Recommendation G.114 [i.6] recommends maximum one-way 
transmission time for an international telephone connection to achieve transparent interactivity. 
ITU-T Recommendation G.114 [i.6] contains the following statements: "if delays can be kept below 
[150 ms], most applications, both speech and non-speech, will experience essentially transparent 
interactivity" and "delays above 400 ms are unacceptable for general network planning purposes". As the 
purpose of inter-destination media synchronization is typically achieving transparent interactivity 
(see also TS 181 016 [47] clause A.9.6), the ITU-T Recommendation G.114 [i.6] is a useful guideline. 

The SC shall not require to receive any RTCP extended Reports (XR) containing synchronization settings instructions. 
The absence of such instructions shall not be taken as a sign that something is wrong. 

NOTE 3: The SC may not receive synchronization settings instructions because RTCP is normally transported 

using the unreliable UDP protocol. The SC may also not receive any instructions if it is the most delayed 
SC in its synchronization group, if it is the only member of its group or if buffering is carried out in the 
ECF/EFF, see clause 10.5.1. 

If the SC is co-located with the MSAS, then the exchange of synchronization status information and synchronization 
settings instructions is internal to the functional entity in which they reside. 

NOTE 4: An example of co-located SC+MSAS functionality is when UEs exchange synchronization status 

information and synchronization settings instructions over an existing direct communication channel, see 
clause A.13.2.3. 

NOTE 5: The algorithm that is used by the SC to synchronize the media based on the synchronization settings 
instructions is a vendor implementation decision. See [i.2] for an overview of techniques. 
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1 0.4 Media Synchronization Application Server (MSAS) 
10.4.1 Procedures for inter-destination media synchronization 

In case of synchronization for a broadcast stream, the MSAS shall function as a Feedback Target, specified in [28]. 
Before forwarding RTCP Receiver Reports to the appropriate MF, the MSAS shall remove RTCP extended Reports 
containing synchronization status information, which are specified in TS 183 063, clause W.l [17]. The MSAS shall 
send synchronization settings instructions to the SC using RTCP extended Report, which are specified in TS 183 063, 
clause W.l [17]. 

The synchronization settings instructions take the form of RTP timestamps, combined with NTP timestamps. The NTP 
timestamp indicates the clock shared by the synchronization group, the RTP time stamps indicate the expected receipt 
and/or presentation time. The MSAS shall send expected receipt times. It should send expected presentation time 
stamps. 

NOTE 1 : Synchronization settings instructions may be interpreted as the synchronization status information of a 
virtual SC to which the addressed SCs may try to synchronize. 

NOTE 2: The algorithm that is used by the MSAS to derive the synchronization settings instructions from the 
received synchronization status information is a vendor implementation decision. See [i.2] for an 
overview of techniques. 

In case of synchronization of Content on Demand or other unicast streams, the MSAS shall forward RTCP Receiver 
Reports to the appropriate MDF. Before forwarding RTCP Receiver Reports, the MSAS shall remove RTCP extended 
Reports containing synchronization status information. The MSAS shall forward RTCP Sender Reports to the 
appropriate SC, appending synchronization settings instructions to the SC using RTCP extended Report. The MSAS 
may send synchronization settings instructions to the SC using a separate RTCP XR. The RTCP XR for sending 
synchronization settings instructions is specified in TS 183 063 [17], clause W.l. 

In case of synchronization in the presence of functional entities that modify or re-originate media streams 

(e.g. a transcoder or a mixer in an MDF), the MSAS shall function as a Third Party Monitor [29]. It shall be able to 

receive and process synchronization correlation information as specified in clause 10.6.2. 

NOTE 3: Synchronization correlation information enables an MSAS to correlate the timing of two related media 
streams. By using NTP time as a reference, the MSAS can determine which RTP timestamp of the one 
media stream corresponds with which RTP timestamp of the other media stream. 

10.5 ECF/EFF 

10.5.1 Procedures for inter-destination media synchronization 

In one mapping of the SC is an adjunct function that may be co-resident with any of the appropriate elements of the 
Transport Processing Function, see clause 4.3.9. If the SC is an adjunct function of the ECF/EFF, then ECF/EFF shall: 



• 



send synchronization status information to the MSAS using an RTCP extended Report (XR), as specified in 
TS 183 063 [17], clause W.l; 

• be able to receive RTCP extended Reports (XR) containing synchronization settings instructions, as specified 
in TS 183 063 [17], clause W.l. 

The ECF/EFF may have partial SC functionality, supporting SC functionality in the UE. This requires that the SC in the 
ECF/EFF is in the path between the UE and the MSAS used. In this case the ECF/EFF shall be able to: 

• Monitor and possibly adjust synchronization status reports going from UE to MSAS. Reported arrival times 
need to be adjusted for the current buffer time the ECF/EFF has introduced. 

• Determine the arrival time for the indicated stream at the SC in the ECF/EFF. 
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• Intercept and carry out synchronization settings instructions. Synchronization settings instructions may or may 
not be forwarded to the SC in the UE. 

NOTE: Combining an SC in an UE with an SC in the ECF/EFF may have advantages for channel changing times 
and synchronization accuracy. When buffering at an UE, channel changing times during the use of a 
shared service session may be quite large if one of the participants is severely lagging behind the others. 
Buffering in the ECF/EFF can reduce channel changing times. This requires the ECF/EFF to pre-buffer 
the channel to which the UE is changing. Furthermore, if buffering is applied in the ECF/EFF, 
measurements from an UE can be used to increase synchronization accuracy. 

1 0.6 Synchronization Client' (SC) 

10.6.1 Procedure for real-time transport 

Clause 10.3.1 is also applicable to SC. 

1 0.6.2 Procedures for inter-destination media synchronization 

The SC shall send synchronization correlation information to the MS AS, which acts as a Third Party Monitor [44] with 
respect to the SC. Synchronization correlation information has the following components. 

• RTCP extended Report (XR) related to the incoming media stream; 

• RTCP extended Report (XR) related to the outgoing media stream. 

XR related to the incoming media steam is specified in TS 183 063 [17], clause W.l. The XR contains the SSRC of the 
incoming media stream, the NTP timestamp and the Packet Received RTP timestamp. The Packet Presented RTP 
timestamp field shall be set empty. 

XR related to the outgoing media stream is specified in TS 183 063 [17], clause W.l. The XR contains the SSRC of the 
outgoing media stream, the NTP timestamp and the RTP time stamp. The Packet Presented RTP timestamp field shall 
be set empty. 



1 1 Procedures using FLUTE for NGN integrated IPTV 

When optional Multicast Download delivery for Push COD is required then FLUTE protocol shall be supported by UE 
and MDF functional entity. 



11.1 User Equipment (UE) 



When Multicast Download delivery is used for PushCOD content then UE shall support FLUTE protocol for download 
and store of PushCOD content as specified in RFC 3926 [30] and TS 102 034 [5] conform to clause 10. 



1 1 .2 Media Delivery Function (MDF) 



The File delivery over Unidirectional Transport (FLUTE) protocol [30] shall be used for PushCOD multicast download 
from MDF to UE. 

In addition to the basic FLUTE protocol as specified in RFC 3926 [30], the PushCOD multicast download is comprised 
of parts that further specify how FLUTE is used in TS 102 034 [5] (as in clause 10). The purpose of file delivery is to 
deliver content items in files. A file may contain any type of data (e.g. AudioA^ideo file, Binary data. Still images. Text 
and BCG metadata). 
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12 Support mobility, interconnection and hybrid 
scenarios 

The UE (converged) should support unicast based service continuation between NGN IPTV UEs for the following 
services ([4], clause 11.12.1): 

Trick modes on broadcast TV. 

Content on Demand. 

Time-shift TV. 

Network PVR. 

UGC. 

Content Bookmarks. 

The UE (converged) should support unicast based service continuation between NGN IPTV UEs and Mobile UE with 
3GPP PSS support for the CoD service (as in [4], clause 11.12.1). 

The UE and NGN based IPTV should support interconnection scenarios refer to [4], annex G. IPTV services supported 
in interconnection and examples of signalling flows for selected services are described in [i.4]. 

The NGN integrated IPTV should be interconnected with Content Delivery Networks (CDN) as following 
TS 182 019[i.l2]: 

• IPTV Control interconnected with CDN via reference point Cu, Qt (CDNCF) or Ct (CCF) using http or 
optionally SOAP/XML. 

• UE interconnected with CDN via reference point Xc' (CCF) and Xd' (CDF) using same protocols as over Xc 
(RTSP or optionally HTTP) and Xd reference point. 

NOTE 1: Because this document is published before publication of TS 182 019 [i.l2] according mentioned 

referenced entities (CDNC, CCF, and CDF) and reference point (Cu, Qt, Ct, Xc' and Xd') there may be 
changes that could not be reflected this time. 

The UE (converged) may support hybrid scenarios to deliver IPTV services with NGN integrated IPTV as described 
in [4], annex I. In this case all protocol on NGN integrated IPTV shall follow this specification. In addition hybrid MDF 
may to support alternative delivery of media over Xd' reference point. Hybrid MDF is Media Delivery Function as 
specified in clause 4.3.6 which additionally to delivery method specified in clause 10.2 may also support existing 
alternative media delivery using for example DVB broadcasting technologies. 

NOTE 2: Alternative delivery of media over Xd' reference point is out of scope for this specification. Example of 
alternative deHvery is mentioned in [4] annex I (e.g. DVB-T, DVB-S, DVB-C and DVB-H). 



1 3 IPTV user profile schema 



NGN Integrated IPTV provides support for several options to access user profile in accordance with the location where 
the user data is: 

• Use UPSF as the host for the set of user related information necessary for multi-subsystems service blending. 

• Use of data federalisation (represented by UDAF). 

If user profile is hosted in a single place, e.g. using UPSF as the host, the IPTV user profile is described by an XML 
document. This XML document complies with the XML schema defined in annex H. 

Although it is not explicit in the XML schema described in annex H, the IPTV user profile must comprise at least 
profiles of mandatory services one BC profile, CoD profile, PVR profile and UE capabilities profile. 
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Annex A (informative): 

Functional entity relations and example signalling flows of 

NGN integrated IPTV operations 

A.1 Functional entities relations and overview of the NGN 
integrated IPTV procedures 



Legenda:NGN integrated IPTV model 

UDP/RTP/RTCP 
Diameter 

RTSP 

HTTP 

IGMP/MLD 

DVBSTP 
Not defined 




NOTE: This figure represents high level relationships and protocols between the functional entities. The detailed 
procedures and signalling flows are presented in the following sections of this clause. 

Figure A.1 : NGN integrated IPTV - protocol model with FE relation 

0) Initially, the UE is required to start or boot (i.e. a set-top-box, PC, mobile or any device with an IPTV client) 
and perform network attachment to obtain network parameters (i.e. an IP address, P-CSCF address, etc.). 

1) After network attachment the UE is required to start service initiation steps. 

2) UE performs service provider discovery in order to enable SD&S procedure followed by IPTV service 
selection and attachment as defined in [4]. SD&S can use HTTP over Tr as describe in clause 6 or DVBSTP 
over Tr as described in clause 9. 

3) Then UE performs the service selection procedures with CFIA via Tr (using HTTP over Tr as described in 
clause 6 to receive service selection information. 
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4) At this stage the IPTV UE needs to acquire and use collected service selection information to establish 
appropriate selected service via CFIA 5). 

NOTE 1 : The IPTV-C is able to initiate resource reservation process for network resources needed by the IPTV 

service according to the capabilities of the UE. The resource reservation and allocation is performed using 
standardized transport control functions of NGN RACS available to the IPTV-C. 

5) Following the successful session initiation, the IPTV-C informs the MCE via Sa interface (or UE in some 
cases, i.e. BC) about identification of selected content from the Media Delivery Function (or ECF/EFF for BC 
services) to initiate delivery of the selected multimedia content (CoD, nPVR). 

6) The UE may interactively control CoD media stream over the Xc interface (between the UE and the MCE) via 
RTSP protocol (as defined in clause 6). The UE may control BC media stream over the Di interface (between 
the UE and the ECF/EFF) with IGMP/MLD protocol (as defined in clause 7). 

7) The MDF performs media delivery over the Xd interface is based on UDP/RTP stream delivery and several 
transport variants (as described in clause A. 2). 

NOTE 2: Fast Channel Change is being discussed by DVB-IPI for the next release. 

A.2 Example signalling flows of service discovery and 
selection 

SD&S mechanisms used for service discovery, selection and the delivery of service discovery information is based 
upon [5], clause 5.2. 

Service discovery enables the discovery of IPTV services available over NGN integrated IPTV subsystem. The service 
discovery results in the presentation of services with sufficient information for the user to make a choice and access the 
chosen service. Selection takes place after the user has made a service discovery. 




SD&S 



1. HTTP GET 




2. Service discovery 
information 



3. HTTP GET 



4. Service selection 

information (HTTP or 

DVBSTP) 



5. Service initiation (service selection) 



Figure A.2: Service discovery and selection procedures 

1) The UE request service discovery information based on [5], clause 5.2. The request may contain other header 
fields conforming to [9] . 

2) The SD&S response with appropriate XML based answer to UE request with service delivery information. The 
response to the HTTP requests above returns the appropriate XML records defined in [5], clause 5.2.6. 
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3) In the pull model of unicast delivery of DVB SD&S data, the HTTP protocol is used conforming to [5], 
clause 5.4.2.2. 

NOTE: In case of push mode this step is not required. 

4) There are two mechanisms defined, one for multicast and one for unicast. The protocol DVB SD&S Transport 
Protocol (DVBSTP), clause 5.4.1 [5] is used. The protocol HTTP [9] is used to transport BCG [8] information 
over unicast. 



A.3 Signalling flow and protocol RTP/RTCP for 
Retransmission 

Protocol using RTP/RTCP for RETransmission (RET). RETransmission solution is optional. 

When RET is used then procedure rely on the RTP retransmission solution as specified in TS 102 034 [5] annex F. 

Procedure may rely on the RTP retransmission solution as specified in [23] and [24], for guaranteeing the delivery of 
the unicast CoD service and broadcast TV services. 

NOTE: RTP/RTCP could be applicable for Fast Channel Change. This work is being discussed by DVB-IPI for 
the next release. 

This clause describes an example of signalling flow for Retransmission. 





1. RTP/UDPco 



ntent 



MDF 
Retr 



Media 
Management 



I 



Service Configuration 



Retain Content for Retr 



Packet Loss 



2. RTCP FB 



3. RTP with lost packet 



Figure A.3: Retransmission signalling 



A.3.1 User Equipment (UE) procedure for BTV service 

For BTV service delivered over RTP/UDP, retransmission service functionality may be signalled towards the UEs. The 
way this is signalled as well as which are the retransmission service configuration parameters is for further study. 

When the UE notices that packet loss may have taken place (based on e.g. RTP sequence number gap detection), it may 
decide to request retransmission of the missing packet(s). This is done by issuing a unicast RTCP Feedback message to 
a feedback target. The RTCP Feedback message has the format of the generic NACK as defined in RFC 4585 [23]. The 
destination port and address of the feedback target is configured at the UE. Upon packet loss detection, the UE may 
wait some time delta T before issuing a retransmission request. This is to allow the feedback target (see further) to send 
a RTCP FB message. If such a FB RTCP message is received from the FB target indicating packet loss corresponding 
with the packet loss detection by the UE, the UE should not issue an RTCP FB message itself. 
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The RTCP FB messages do not have to be sent in compound RTCP messages by the UE (i.e. they can be sent 
stand-alone without SDES or RR). The feedback target for the RTCP FB messages can be different from the compound 
RTCP messages (carrying SDES and RR), and the compound RTCP messaging may be even suppressed upon 
configuration. 

The feedback target also hosts the retransmission server from which the UE should expect the retransmissions. The 
packets that are retransmitted are formatted according to the [24]. The retransmissions can be sent either in unicast or in 
multicast. When the packets are retransmitted in multicast, they have the same multicast group address of the original 
MC RTP stream, but a SSRC identifier is used different from the one in the original stream. When the packets are sent 
in unicast, the SSRC identifier can be identical to the SSRC of the MC stream carrying the original RTP packets. 

The UE supports reception of RTCP messages sent by the feedback target over MC with the same MC group address as 
the MC stream carrying the original RTP packets. These RTCP messages can be RR, SDES, FB messages [23]. As 
described above, a FB message sent out by the Feedback target towards the UE is used for packet loss signalling in 
order to have the UE abstaining from FB messages itself for the signalled packet loss. 

The FB target may also send out Receiver Summary Information (RSI) RTCP messages. RSI messages are formatted 
according RTCPSSM draft (reference) and allow to signal e.g. maximum (upstream) RTCP bandwidth that can be 
consumed by the UE. 

The UE can issue multiple retransmission requests to take into account loss of retransmission packets or retransmission 
requests (RTCP FB message), based on e.g. a time-out mechanism. The maximum number of retransmission requests 
associated with the same packet loss event that can be issued by the UE is application specific. 

The way this is signalled as well as which are the retransmission service configuration parameters is for further study. 

The candidate configuration parameters are: 

• Common IP address of the Feedback Target and Retransmission Server. 

• Destination Port number of RTCP upstream messages. Destination Port number of unicast RTP 
retransmissions. 

NOTE 1: The above given parameters may be different for each corresponding MC original stream. Optional: 
separate IP address and port for compound RTCP messaging (RR and SDES). 

• Payload type number of RTP retransmission packets. 

• Delta T = Minimum waiting time between packet loss event detection and sending out RTCP FB message by 
UE (to allow reception of RTCP FB messages from Feedback target, which cancel the outstanding UE RTCP 
FB message). 

• Upstream RTCP bandwidth that can be consumed by the UE. 

• The time a packet is available for retransmission. 

NOTE 2: If DVB-IPI is extended to include configuration parameters they should be applicable. 

A.3.2 User Equipment (UE) procedure for CoD service 

For CoD service delivered over RTP/UDP, retransmission service functionality may be signalled towards the UEs. 
RFC 4585 [23] and RFC 4588 [24] define how retransmissions is supported. 

When the UE notices that packet loss may have taken place (based on e.g. RTP sequence number gap detection), it may 
decide to request retransmission of the missing packet(s). This is done by issuing a unicast RTCP Feedback message to 
a FB target which may coincide with the CoD server. The RTCP Feedback message has the format of the generic 
NACK as defined in RFC 4585 [23]. The destination port and address of the feedback target (when different from the 
CoD server) is configured at the UE. 

The RTCP FB messages do not have to be sent in compound RTCP messages by the UE (i.e. they can be sent 
stand-alone without SDES or RR). 

NOTE 1 : Compound RTCP messages (carrying SDES and RR) may be even suppressed upon configuration. If 
used they are sent to the CoD server. 
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The feedback target also hosts the retransmission server from which the UE should expect the retransmissions. The 
packets that are retransmitted are formatted according to the RFC 4588 [24]. The SSRC identifier in the unicast 
retransmission packets is different from the SSRC of the original RTP packet stream, and the same session address/port 
is used. 

The UE can issue multiple retransmission requests to take into account loss of retransmission packets or retransmission 
requests (RTCP FB message), based on e.g. a time-out mechanism. The maximum number of retransmission requests 
associated with the same packet loss event that can be issued by the UE is application specific. 

The way this is signalled as well as which are the retransmission service configuration parameters is for further study. 

The candidate configuration parameters are: 

• common IP address of the Feedback Target and Retransmission Server; 

• destination Port number of RTCP upstream messages; 

• payload type number of RTP retransmission packets; 

• upstream RTCP bandwidth that can be consumed by the UE; 

• the time a packet is available for retransmission. 

NOTE 2: If DVB-IPI is extended to include configuration parameters they should be applicable. 



A.4 Example signalling flows of nPVR 

This clause describes an example of nPVR signalling . nPVR service as typically delivered as CoD service and the CoD 
flows from annex C apply. 



UE 



CoD MF 



IPTV 
Control 




nPVR Content Selection 



1 . http nPVR content capture 
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request 



ontent capture request 
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5. Record 
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Figure A.4: nPVR signalling flows 
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User selected Asset from the list of Assets available for nPVR from Customer Facing IPTV application. 

1) The UE sends an http request to initiate content capture to the CF IPTV Apps. 

2) The CF IPTV Apps asks IPTV control to record the Asset and create recording schedule. 

3) The IPTVC selected MDF for the recording. 

4) The IPTVC passes the recording schedule to MDF. 

5) The MDF records the program. 

After the recording has started the program is available as normal CoD asset. Flows defined in annex C are applicable. 

A.5 Example signalling flows of IPTV service for 
messaging 

Common NGN ASF should be used for messaging as discussed in clause 5.1.6. 

In case messages are delivered via CFIA as shown in figure A.5, the role of Common NGN ASF is to terminate and 
process multiple incoming messages (i.e. SIP, MM7, SMTP, other) into generic XML schemas, which are then passed 
to CFIA for presentation to the UE. The responses from the UE via CFIA should be passed back to Common 
NGN ASF, which will route the messages to the appropriate destination. 

A.5.1 Example signalling flows of IPTV service for messaging 
using HTTP 




IPTV ASF 
(CFIA) 



2. HTTP POST 
(Message) 



8. HTTP 200 OK 



NGN ASF 



3. HTTP GET 
(Message) 
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4. Check profile & messaging 
forwarding 



6. Deliver Message 



7. Confirm delivery 



to destination HTT^* POST 



HTTP 200 OK 



9. Present/ Announce 
incoming message 



Figure A.5: Messaging between IPTV UEs using HTTP for messaging 

The detailed description of the protocols and messages flows: 

1) User 1 sends message to the IPTV user 2. 

2) The UEl sends HTTP request with attached message and destination identifier to the CFIA. 

3) The CFIA forwards message to the NGN ASF messaging server. 
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4) According to policies the NGN ASF may request IPTV sub-profile of federalized user profile from 

NGN UDAF if this information is not stored in NGN ASF. The NGN ASF identified destination UE based on 
policy and destination information. 

5) If based on policies the message could be forwarded to the IPTV UE2, the Common NGN ASF informs CFIA 
about the incoming message. 

6) The CFIA delivers message to UE 2. The notification message is delivered to the UE 2 (via HTTP and 
Tr interface) using internal Notification mechanism as described in clause B.8. 

7-8) Successful delivery is confirmed to UE 1 via CFIA. 

9) The message is presented to user 2. 

NOTE: The message can be directly delivered from and to Common NGN ASF. 

To simplify the message processing, user actions can be packed together with the messages, e.g. to reply to the message 
or to store the received message in the user message box. The user selection can be passed back to the Common ASF 
for processing, i.e. to remove message specific processing from the UE. In this case the following XML schema is 
recommended as defined in annex C. 

A.5.2 Example signalling flows of IPTV service for messaging 
using SIP 
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Figure A.6: Messaging between from SIP capable UEs to IPTV UE 

1) The UEl is a SIP capable device, compliant with [10] or for interaction with IMS core compliant with [11]. 

2) The UEl generates and sends a SIP MESSAGE to the SIP proxy. 

3) The SIP proxy forwards message to NGN ASF. 

4) The NGN ASF checks user profile and policy for incoming messages and based on this information it 
forwards the message to IPTV UE2 network. 
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5-6) The Message is delivered and presented or stored in message box of the UE2. 

7-9) The response is replied back to the UEl via Common NGN ASF. 

NOTE: The delivery to the IPTV UE can be both directly from the Common NGN ASF and via the CFIA as 
described in the above flow. 

The flows above are applicable to the delivery of messages from other sources such as IMS-IM (SIP), MMS/SMS 
(MM7, SMPP), e-mail (SMTP), other to IPTV UE via a single notification interfaces utiHzing either HTTP or SIP. 

To simplify the message processing, user actions can be packed together with the messages, e.g. to reply to the message 
or to store the received message in the user message box. The user selection can be passed back to the Common ASF 
for processing, i.e. to remove message specific processing from the UE. In this case the following XML schema is 
recommended as defined in annex C. 



A.6 Example signalling flows of IPTV presence services 

A.6.1 Example signalling flows of IPTV presence notification 
using PA 
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Figure A.7: Presence services to IPTV UE using PA 

1) The UEl may subscribe to presence service information and use HTTP POST to request the information via 
CFIA. 

2) The CFIA forwards the request to NGN ASF to check the user profile. 
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3) The NGN ASF may check profile and perform authorization for usage of presence service within the IPTV. 

NOTE 1: Authorization regarding the submission of presence information from the presence service may use [15] 
with authorization rules content [16] independently. The exact procedure is outside the scope of the 
present document. For the current flows it is assumed that UE2 authorized access to the presence. 

4) The NGN ASF subscribes to the presence information on behalf of the user. 

5) The subscription is confirmed to the NGN ASF. 

6) After the initial subscription PS sends initial presence status via SIP NOTIFY (actual presence if any 
available). 

7) The notification is confirmed to the PS. 

8) The presence state changes or is published for first time. 

9) The PS informs the NGN ASF about presence state change using SIP NOTIFY. 

10) Notification is confirmed to the PS. 

11) The NGN ASF generates http 200 OK with attached presence information in XML document. 

12) The presence information is forwarded to the UEl . 

NOTE 2: For steps 1 1 and 12 HTTP POST may be alternatively used to deliver presence information to the UE. 

13) The UEl displays information or updates presence status on user interface. 

The Presence User Agent in the Common NGN ASF may report presence directly to the converged IPTV UE in step 1 1 . 

The Presence User Agent may perform presence status collection and reporting from NGN IPTV to NGN Presence 
Server. 
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A.6.2 Example signalling flows of IPTV presence notification 
using RLS 
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Figure A.8: Presence services to IPTV UE using RLS 

1) The UEl may subscribe to presence service information and use HTTP POST to request the information via 
CFIA. 

2) The CFIA forwards the request to NGN ASF to check the user profile. 

3) The NGN ASF may check profile and perform authorization for usage of presence service within the IPTV. 

NOTE 1: Authorization regarding the submission of presence information from the presence service may use [15] 
with authorization rules content [16] independently. The exact procedure is outside the scope of the 
present document. For the current flows it is assumed that UE2 authorized access to the presence. 

4) The NGN ASF subscribes to the presence information on behalf of the user. The request is sent to a Resource 
List Server as described in [14]. 

5) The RLS subscribes on behalf of the user also to presence information of all users, In this particular case, the 
user supplying presence is the UE2. 

6) The subscription is confirmed to NGN ASF. 

7) After the initial subscription the PS sends presence via SIP NOTIFY (if any is available). 

8) The UE2 informs the RLS about changes in the presence state via SIP NOTIFY. 

9) The RLS sends resource-list notification as described in the [14]. 

10) The notification is confirmed via SIP 200 OK. 



ETSI 



54 



ETSI TS 183 064 V3.4.1 (2011-02) 



11) The NGN ASF generates http 200 OK with attached presence information in XML document. 

12) The presence information is forwarded to the UEl. 

NOTE 2: For steps 1 1 and 12 HTTP POST may be alternatively used to deliver presence information to the UE. 

13) The UEl displays information or updates presence status on user interface. 

The Presence User Agent in the Common NGN ASF may report presence directly to the converged IPTV UE in step 1 1 . 

The Presence User Agent may perform presence status collection and reporting from NGN IPTV to NGN Presence 
Server. 

A.6.3 Example signalling flows of IPTV presence updates 
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Figure A.9: Presence information about IPTV services used by UE1 

The IPTV UEl may inform IPTV application server about state of services used by the UEl. 

1) When new event occurs or IPTV appHcation server makes an update request, the UEl may send related 
presence information in XML format. 

2) The UEl generates and sends XML presence state to the CFIA. 

3) The information is processed and forwarded to the to the presence agent in the Common NGN ASF. 

NOTE: Structure of XML document may follow XML schema defined in [17], annex E: "XML schema for IPTV 
presence document extension" . 

4) The presence information is updated. 

5-6) The presence update is confirmed to the UEl via HTTP 200 OK. 

Alternatively, the Presence User Agent or Presence Network Agent may perform presence collection and reporting from 
NGN IPTV to NGN Presence Server. 
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A.7 Example signalling flows of IPTV service interaction 
with NGN/IMS services 

This clause provides description about interaction procedures between IPTV and other NGN/IMS service level 
subsystems, e.g. IMS, for composite services. In the data flows it is assumed that both IMS users (IMS UE) are 
registered in IMS subsystem. The procedure describes several types of the interactive features in converged NGN IPTV 
applications (e.g. presenting a caller ID of an incoming call on the TV screen). 

A.7.1 Example signalling flows of IPTV service handling of 
incoming calls 

In this scenario User 1 calls towards User 2 and both have their IMS UEs in IMS domain. User 2 is subscribed to a 
converged IPTV service (e.g. caller ID notification with options to accept, forward or reject incoming call when his 
IPTV service is active) via the IPTV UE (which have service mapping/relationship with IMS UE 2). 

There may be supported at least 3 cases for incoming call handling: 

• confirm acceptance of incoming call; 

• refuse call; 

• forward call to voice mail or other terminal. 
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Figure A.10: High level interactions procedure between IPTV and 
other service level subsystems - NGN/IMS inter-working with NGN integrated IPTV 

NGN ASE should be used for mapping SIP messages to generic XML schemas which should be processed by 

IPTV ASE that will present information to IPTV UE (and receive/forward user reaction, e.g. confirmation for receiving 

call back to core IMS) related to user IMS UE. 
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The detailed description of the used protocols and messages is following: 

1) A usual SIP INVITE message with information about destination user, call originating user, type of call, 
optionally further parameters is forwarded from NGN (core IMS). 

2) S-CSCF access user profile data. Dotted line indicates that IMS user profile has been requested from UPSF 
(at regular IMS registration). 

3) Based on IMS user profile the SIP INVITE is forwarded by the S-CSCF to the NGN ASF via ISC interface. 
NGN ASF acts for the S-CSCF as an IMS AS that can receive SIP messages. A mapping between the SIP 
identifiers from SIP INVITE message and corresponding IPTV UE device ID (of User 2) can be required. 
The mapping identifiers may be performed within NGN ASF using information about user stored locally or 
e.g. in the NGN UDAF (but detail process or place of storage for this information is out of scope for the 
present document). 

NOTE 1: In case that user 1 sends messaging/notification information via SIP MESSAGE to user 2 same mapping 
of SIP identifiers could be applied for delivery information ant their transformation to presentable format 
to IPTV UE of user 2. 

4) According to policies the NGN ASF may request IPTV sub-profile of federalized user profile from 
NGN UDAF if this information is not stored in NGN ASF. 

5-6) Optionally the request can be also forwarded to lUDF. The exact specification of this is out of scope for the 
present document. 

7) When required user data and service information are delivered and available for the NGN ASF. Further steps 
are performed if user has subscription for such converged service activated and IPTV UE is online. 

8) A mapping from SIP messages to the XML message is performed by the NGN ASF. The XML notification 
message is used for that delivery and presentation service information to IPTV UE (directly or via Client 
Facing IPTV application - step 9). 

The mapping of relevant information from SIP message to XML have to be generated by NGN ASF 
including required SIP identifiers and service information (e.g. call line ID transferred in the XML 
notification message) in form presentable by IPTV ASF (Client Facing IPTV Application) or finally to the 
IPTV UE. Mapping is following: 

SIP identifiers of destination URI mapped to IPTV UE ID of User 2 (the mapping has been already 
performed); 

SIP identifier of originating URI with information about User 1 (information who is calling or sending 
message); 

SDP parameters - optionally service information and parameters about the call like subject, type of call 
(emergency, priority), etc. 

9) The service information can be then presented to IPTV UE from IPTV ASF (via Tr and using HTTP). 

10-12) The IPTV ASF may require future action from User 2 on IPTV UE whether user has for example accepted 
the call or rejected. This response messages are returned back to NGN ASF which will react appropriate way 
back towards IMS (e.g. forwarding back SIP INVITE to IMS UE of User 2). 

NOTE 2: Similar mechanisms may be used also for interaction with other services such as presence or messaging. 

NOTE 3: Similar procedure should be used for IPTV interaction with SIP based architecture based on 
RFC 3261 [25] (in this case SIP proxy is used instead of S-CSCF). 
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A.8 Example signalling flows of Notifications 

Common NGN ASF may be used for external notification services to the IPTV UE as described below, i.e. for 
emergency alerting, advertising or maintenance notification (where non-IPTV NGN ASF request notified the 
IPTV UE). 
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Figure A.11 : Notification services to IPTV UE 

The description of the protocols and messages illustrated below. 

1) The User 1 subscribes to the Notification service. 

2) The NGN ASF confirms successful subscription by 200 OK. 

NOTE 1 : Steps 1 and 2 may be performed via CFIA, in this case the steps may be directly between NGN ASF and 
UEl. 

3) The notification event occurs and the NGN ASF performs action to inform the User 1. 

4) The NGN ASF may request IPTV sub-profile of federalized user profile from NGN UDAF and policies. The 
NGN ASF may decide, i.e. based upon received profile or policies, the right UE to send the notification to. In 
this case the IPTV UEl is selected, but different UE, i.e. SIP based, may be used. 

5) The NGN ASF informs the CFIA about notification event which should be presented to UE. 

6) The IPTV ASF confirms receiving information with notification data in XML format (e.g. the UE identifier, 
notification message, etc.). 

NOTE 2: Steps 5 and 6 are not required when direct notification to the UE is used, i.e. SIP based. 

7) The notification message is delivered to the UE 1 (via HTTP and Tr interface) using internal Notification 
mechanism as described in B.8. 

8) The deHvery is confirmed to the NGN ASF. 

NOTE 3: Steps 7 and 8 may be performed via CFIA or directly between the NGN ASF and UEl. 
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9) The notification information is present to the user or stored in the UE message box. 

NOTE 4: Notification methods should use HTTP over Tr interface. Optionally for SIP enabled UE, the SIP 
notification should comply with [18]. 

User actions can be delivered together with the notification and user selection passed back to the Common ASF for 
processing, i.e. to simplify message processing on the UE and remove specific message processing logic from the UE. 
In this case XML schema defined in clause A. 5 is recommended. 



A.9 Example signalling flows of Targeted Advertising 

The targeted advertisement content is selected by the ADS (Ad Selection Service). 

Ad insertion opportunities and key ad insertion steps for unicast and multicast based services defined in clause 1 1.10 [4] 
apply. 

A.9.1 Network side unicast based advertisement 

This clause defines network side advertisement procedures for pre-roll, post-roll and pause ad placement opportunities 
discussed in clause 11.10 [4]. 

Figure A. 12 presents network side pre-roll and post roll advertisement procedure for unicast based services. 

The procedure is applicable for the following services: 

Content on Demand. 

- Network PVR. 

- Time-shift TV. 




-6. Personalised play-list- 
7. 



-8. Acknowledgement and personalised playlist- 



9. Unicast Session Setup 



4. ADx: Ad 

Request 
5. 



Figure A.12: Pre-roll and post-roll advertisement for unicast based services. 

1) User selected a content following SD&S procedure discussed in clause 6.3. 

2) CFIA optionally requests current profile in order to request an ad. 

3) UPSF/IUDF returns current profile. 
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4) ADM in the CFIA requests personalised ads from ADS on Adx interface as defined in clause 5.1.8. XML 
schema carried over HTTP applies++ conforming to SCTE 130-3 [i.l3]. Optionally Adm may request 
additional ad related information from POIS and SIS. 

5) ADS returned content identifiers for personalised ads on Adx. 

6) CFIA passes to MCF (s personalised play lists containing main selected content and ads. Optionally trick 
mode operations can be disabled for ads sat the time of play-list creation. 

7) MCF confirms creation of the play-list. 

8) CFIA returns name of the personalised play-list in the asset URL. 

9) UE initiates unicast session setup. Normal procedure for corresponding service type (e.g. CoD, nPVR) applies. 



A.10 Example signalling flows of User Generated Content 
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Figure A.13: UGC creation procedure 

The UGC procedure comprises the following steps: 

1) The UE sends a request for User Generated Content declaration. 

la) The UE sends a User Generated Content Declaration http GET Request to the CFIA. 

lb) The CFIA may check user rights and user profile prior to granting the UE permission to create UGC and 
generates a unique UGC ID. UGC ID is location independent, globally unique and should be accessible 
by other UEs. 
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Ic) The CFIA confirms that the UE is authorised to create UGC by sending 200 OK a Declaration Response 
containing the UCG ID and the designated MCF/MDF where the UCG can be created 
(uploaded/upstreamed) . 

2) The UE sends a request for UGC description 

2a) The Description Request http POST contains a description of the User Generated Content: name, type, 
restriction, textual description, selected group users, type of content, coding. 

2b) The CFIA records the UGC description, attaches UGC ID and UGC description and sends a UGC 
Description Response to the UE with 200 OK. 

3) UE initiates creation of User Generated Content for uploading or upstreaming the content to the designated 
MDF and confirms to the CFIA the publication of the content. 

4) The CFIA links UGC ID, UGC description and UGC location (address), and publishes this UGC information 
to the SD&S. CFIA should used existing notification mechanism to announce new UGC content to notify 
concerned UEs via user interface (http procedures used as in clause 5.1.5). The UGC description publication 
by the CFIA in step 4 may take place before, during or after the UGC content creation in step 3. The CFIA 
notifies UEs that have pre-selected the UGC as per clause 5.1.9. 



A.1 1 Example signalling flows of Content 
Recommendation 




NGN ASF 
PS 



UPSF/ 
lUDF 



SD&S 
CRA 



CRS 



1 . Aoquisition of metadata and user profiling for CR 



Ftecommendation 
request and 
delivery 



2. Recommodation trigger 



-5. Notification with personalised content recommendations — 



3. http request 
-recommendations^ 

for I PTV services 

4. http response 

4 with list of - 
recommendations 



6. Consumption or bookmarking based on CR 



Figure A.14: Recommendation request and delivery 
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Recommendations Request and Delivery 

1) Aggregation and user configuration of profile or preferences for CRS using HTTP on Tr interface. CFIA may 
collect other information for user profiling and identification of user preferences and expectation for CR. The 
Content Recommendation function with service logic and metadata (recommendation) is exposed by CRS. 

2) CFIA or external CRS system triggers recommendation events to request content recommendation to for the 
UE. 

3) CFIA request content recommendation from CRS using HTTP GET request for specified user and 
recommendation type. Request is identified by unique request ID. 

4) CRS replay with http response containing list of recommendations. 

5) CFIA notified UE via HTTP notification mechanism or push content delivery. 

6) If user accepts recommendation UE shall request delivery of recommended content using existing procedures 
for particular content type (e.g. CoD, BC, UGC, PushCoD, etc.) or generate content bookmark for later 
consumption. 

NOTE: The service delivery itself is not affected by the service recommendations. The case when video based 
content recommendation (e.g. trailer) is streamed from MDF is not shown in this procedure but it is 
expected that follows existing procedure (e.g. CoD, BC, UGC, PushCoD, etc.). 



A. 12 Example signalling flows of Content Bookmarks 

An IPTV Content Bookmark service consists of two main steps: 

• creation of IPTV Content Bookmark: allows a user to create and store configurable pointers to content, 
e.g. entire or parts of content (favourite scene) to be able to quickly access the content; 

• retrieval of IPTV Content Bookmark: allows to exchange and share IPTV favourite data. 

Figure A. 15 provides an overview of IPTV Content Bookmark creation and retrieval. This procedure is applicable at 
any time during IPTV session (e.g. during BC, CoD, nPVR session) or at the SD&S stage (e.g. EPG browsing). 



UE 






1 http Request to create IPTV 
content bookmarks 



4. IPTV Content Bookmirk creation respons(i 



2. Check rights, user profile and 
store Content Bookrrark 



3. Add CM metadata to SD&S 




SD&S service selection or consumption of IPTV content 



5. IPTV Content Bookm irk 



: retrieving request 

► 



6. Acquire Content Bookmark 



7. IPTV Content Bookmark retrieving respond ^ 



Figure A.15: Creation, storage and retrieval of IPTV Content Bookmark 
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1) The UE requests CFIA via Tr using http POST to create Content Bookmark and optionally supplies additional 
data (e.g. description). The bookmark data may include content information and at minimum requires content 
and position identifications. 

NOTE: The translation of the content bookmark into the actual byte position within the content files is highly 
dependent on the encoding and storage technique and is outside the scope of this specification. 

2) The CFIA may check user profile prior to creating content bookmark. CFIA creates bookmark and generates a 
unique content bookmark ID. Content Bookmark should be stored in user profile. 

3) The CFIA may inform SD&S about the Content Bookmark creation and update SD&S over Ss' with metadata. 

4) The CFIA confirms creation and storage of Content Bookmark data. 

5) The UE sends to CFIA request via http over Tr for retrieval Content Bookmark. 

6) The CFIA requests Content Bookmark and generate response including content identification, pointer to the 
bookmarked position, additional metadata. The information should be sufficient to initiate content delivery 
from the bookmarked position. 

7) The CFIA send content bookmark to UE as part of replay/restart content offer. 



A.13 Example signalling flows for inter-destination media 
synchronization 

A. 13.1 Inter-destination media synchronization flows for HTTP 
signalling 

A. 13. 1.0 General 

The functional entity "MSAS" in this clause refers to the session-level MSAS, see also clause 4.3.9. 

This clause describes an example HTTP signalling flow to initiate inter-destination media synchronization. 



sc 



MSAS 



1. HTTP GET 



2. HTTP 200 OK 



Figure A.16: HTTP signalling for initiating inter-destination media synchronization. 

1) The SC sends an HTTP GET request to the MSAS, which contains the synchronization group identifier 
(SyncGroupId). See clause 5.1.15 for details on the use of SyncGroupId. 

2) The MSAS responds with a HTTP 200 OK to the SC, which contains the SyncGroupId and adds the MSAS 
parameters (SSRC-ID, address and port number and RTCP SyncGroupID). 
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If the SC and MS AS are mapped on the UE and CFIA, respectively, then the sync interface maps on the Tr interface, 
and the shown flow in Figure 30 may be mapped on the flows for service initialisation, see also TS 182 028 [4], 
clauses 6.2.1 and 6.2.2. 

A. 13.2 Inter-destination media synchronization flows for RTCP 
signalling 

A.1 3.2.1 General 

The functional entity "MSAS" in this clause refers to the session-level MSAS, see also clause 4.3.9. 

A. 13.2.2 Inter-destination media synchronization of BTV service 

This clause describes an example RTCP signalling flow for the exchange of using synchronization status and settings 
instructions exchange from clauses 10.3 and 10.4. 



SC 



MSAS 



l.RTCPRR + XR(status) 



2. RTCP XR(settings) 



Figure A.1 7: RTCP signalling for the exchange of synchronization status and 
settings instructions for a BTV service 

1) The SC sends RTCP Receiver Report (RR) to the MSAS. This report includes an extended Report (XR) 
containing the synchronization status information according to TS 183 063 [17], clause W.l. 

2) The MSAS sends an RTCP XR containing synchronization settings instructions directly to the SC according to 
TS 183 063 [17], clause W.l. 

NOTE: The MSAS may forward RTCP RR to the source of the media. RTCP SR are sent directly from media 
source to SC. 

A. 13.2.3 Inter-destination media synchronization of CoD service 

This clause describes an example RTCP signalling flow for the exchange of using synchronization status and settings 
exchange from clauses 10.3 and 10.4. 
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SC 



MSAS 



l.RTCPRR + XR(status) 



4. RTCP SR + XR(settings) < 



MF 



2. RTCP RR 



3. RTCP SR 



Figure A.18: RTCP signalling for the exchange of synchronization status and 
settings instructions for a CoD service 

1) The SC sends RTCP Receiver Report (RR) to the MSAS. This report includes an extended Report (XR) 
containing the synchronization status information according to TS 183 063 [17], clause W.l. 

2) The MSAS removes the XR from the RR and forwards the RR to the source of the media. 

3) The MF sends its RTCP Sender Reports (SR) to the MSAS. 

4) The MSAS adds the XR containing the settings instructions according to TS 183 063 [17], clause W.l to the 
SR, and forwards this to the SC. 

A.1 3.2.4 RTCP exchange between UEs directly 

This clause describes an example RTCP flow for inter-destination media synchronisation between two UEs directly. 
Both UEl and UE2 have SC functionality. UEl acts also as MSAS, see figure A. 18a. If the RTP/RTCP flows are 
handled by a server (e.g. a conference bridge), then the MSAS functionality may also be located there. 




Sync 




Figure A.1 8a: UE acting as MSAS for inter-destination media synchronization 

between UEs 
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Figure A. 1 8b shows an example RTCP flow for inter-destination media synchronisation between two UEs directly. 



UE2 (SC) 



UEl (MSAS) 



CFIA 



l.RTP/RTCP exchange 



MP 



2. BTV/CoD session 



3. BTV/CoD session 



4. RTCP RR 
+ XR (status) 



5. RTCP 
XR (settings) 



1) 

2)-3 
4)-5) 



Figure A.18b: RTCP signalling for the exchange of synchronization status and 
settings instructions between UEs directly 

UEl and UE2 have a media session, which includes regular RTP/RTCP exchange for the media transport 
and transport control. 

UEl and UE2 each have a BC or CoD session for the same service and content. 

UEl and UE2 reuse their regular RTCP SRs and RRs to append RTCP Extended Reports (XR) [27] for the 
exchange of synchronisation information. See also clauses 10.3 and 10.4. 



UEl and UE2 have to obtain the SyncGroupID, the SSRC value and the MSAS address (=UE1 address) before step 4. 
These may be obtained using the procedures as described in clauses 5.1.16.1 and 5.1.16.2. 

A. 13.2.5 RTCP exchange for sync' 

This clause describes an example RTCP flow for sync', see figure A. 18c. 



SC 




MSAS 




1 


. RTCP XR 

(correlation) 

















Figure A.18c: RTCP flow for sync' 

1) SC sends MSAS synchronization correlation information: RTCP extended Reports (XR) related to the 
incoming media stream and RTCP extended Reports (XR) (TS 183 063 [17], clause W.l) related to the 
outgoing media stream, see TS 183 063 [17], clause W.l. 

Synchronization correlation information may be sent from SC to MSAS at regular pre-configured time intervals. 
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Figure A.18d are example RTCP XR messages for sync', see also TS 183 063 [17], clause W.l. 

12 3 

01234567890123456789012345678901 

I V=2 I P| reserved | PT=XR=2 07 | length=9 | 

I SSRC of packet sender SC ' | 

I BT=9 |SPST=3 |0| block length=7 | 

I FT I Reserved | 

I Media Stream Correlation Identifier, same for in and out | 

I SSRC of incoming media stream | 

I Packet Received NTP timestamp, most significant word | 

I Packet Received NTP timestamp, least significant word | 

I Packet Received RTP timestamp | 

I Packet Presented NTP timestamp = empty | 



12 3 

01234567890123456789012345678901 

I V=2 I P| reserved | PT=XR=2 07 | length=9 | 

I SSRC of packet sender SC ' | 

I BT=9 |SPST=4 |0| block length=7 | 

I PT I Reserved | 

I Media Stream Correlation Identifier, same for in and out | 

I SSRC of outgoing media stream | 

I Packet Received NTP timestamp, most significant word | 

I Packet Received NTP timestamp, least significant word | 

I Packet Received RTP timestamp | 

I Packet Presented NTP timestamp = empty | 

Figure A.18d: Example RTCP messages for sync' 



A.14 Example signalling flows of Personalized Channel 

Personalized Channel (PCh) service allows user to define and watch one or multiple pre-configured/scheduled content 
items as a single (virtual) channel. Personalized Channel information is stored in the user service profile (PCh 
information). 
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UE 



RACS 



1. PCh Sen ice http GET request (purchase & setup) 



^ 3, .PCh_Configuration_ 

^ 3. PCh Configuration confirmation 



MCE/ 
MDE 



5. PCh notifies 



6. Resource reservation 



8. PCh cor tent deHvery 



IPTV-C 



tion 



CEIA 



UPSE 



lUDE 



2. Request authorization 



I 



3. PCh Configuration 



REPEAT 



4. PCh event based on schedule 



5.P(Jh imtiatioili 

< 



7. PCh initiation of content 
ieHvery 



9. PCh service Termination 



Figure A.19: Overview of PCh service procedures 

1) User selects and purchases content for PhC, e.g. from the offers provided by SD&S. UE requests Customer 
Eacing IPTV Applications to setup PCh service with HTTP GET request. 

2) CEIA checks service access authorization with UPSE/IUDE. 

3) User defines and configures personalized channel via Tr using CEIA with selection of one or more content 
items discovered via SD&S, and send by HTTP POST as XML with define name/ID for the channel, items 
on the channel, order, time when each item should be played. Channel definition is confirmed to the UE. XML 
schema for Personalized Channel playlist is defined in annex I. 

4) Optionally, PCh event (e.g. start of the channel or play out of the new scheduled content item) may trigger 
CEIA notification to the UE, e.g. via notification. 

5) CEIA initiates PCh service by HTTP POST via Ss interface towards IPTV-C based on service logic, PCh 
schedule and user availability to watch personalized channel. 

6) IPTV-C reserves required resources via Gq' to RACS. 

7) IPTV-C notifies UE and MCE (depending if redirect or proxy mode is used) to start delivery of the 
personalized content from MDE based on agreed playlist (defined in annex I). 

8) MDE delivers the content to UE on Xd interface using existing procedures for content delivery CoD, BC, 
PushCOD procedures. 

NOTE: Content could be controlled as for any CoD service via Xc reference point from UE using RTSP or 
optionally HTTP. 

9) PCh can be terminated either by MCE or UE. MCE may terminate PCh when all the content on the channel has 
been delivered to the UE, or when the channel or user subscription has expired. 
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Annex B (normative): 

UE capabilities and example Signalling flows of NGN 

integrated I PTV operations 



B.1 UE capabilities 



UE supports following specifications as described in annex D. 



B.2 Signalling flows of BTV 

This clause describes an example of signalling flow of session initiation and termination for BTV. 



UE 



ECF/EFF 



I 



SD&S 

And 

CF IPTV 

Apps 



X 



Content Selection: Multicast Address 



1. Multicast R 



Session Initiation 



iport (Join) 



2. Resource Reservation & 
Admission Control 



Media Stream 



1. Multicast Roport (Leave) 



Session Termination 



2. Resource Release 



Figure B.1 : Signalling flows for BTV operation 

ECF/EFF is typically a part of the Access Network as shown on TS 182 028 [4], figure 4. 

User selected BTV channel during SD&S process. UE has received multicast address to join. 

To start the service: 

1) The UE sends a multicast Join request (Membership Report Message (IGMP) or Multicast Listener Report 
Message (MLD) ) to start receiving multicast media stream. The UE populates the message as follows: 

multicast Address field is set to the multicast address to be joined; 
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if the protocol is IGMPv3 or MLDv2: 

■ if source addresses have been advertised, the Record Type is set to "ALLOW_NEW_SOURCES" 
ECF/EEFd Source Hst is set to the source addresses; 

■ if no source address has been advertised, the Filter mode is set to "EXCLUDE" and Source list is 
set to "empty". 

2) Local resource reservation and admission controlled is performed by the ECF/EEF as defined in [3]. 

Media stream is delivered. 

To leave the service: 

1) The UE sends a multicast Leave request (Membership Report Message (IGMP) or Multicast Listener Report 
Message (MLD) ) to stop receiving multicast media stream. The UE populates the message as follows: 

multicast Address field is set to the multicast address to be left; 

if the protocol is IGMPv3 or MLDv2: 

■ if source addresses have been set in the Join message, the same source address list is excluded from 
the listening interface; the Record Type is set to "BLOCK_OLD_SOURCES" and Source list is set 
to the source address; 

■ if no source address has been set in the Join message. Filter Change record is set to INCLUDE with 
an empty source list. 

2) Local resource release is performed by the ECF/EEF as defined in [3]. 

NOTE: Together with the service request, the key exchange and delivery of security metadata to the UE may be 
initiated in accordance with the media content protection model as described in NGN security architecture 
TS 187 003 [i.l7]. 
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B.3 Signalling flows of CoD 

This clause describes an example of signalling flow of CoD session initiation and termination. 



B.3.1 CoD Session initiation 



UE 



RAGS 



CoDMF 
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IPTV 
Control 



Content Selection: RTSP Asset URL 



1. RTSP SETUP (Asset URL) 




2. Select CoD MCF 



3. Reserve and Commit Resources between MDF/MDF BGF and UE 



4. RTSP REDIRECT (MCF address, Resources_Conf_ID) 



( 5. Est TCP Connection for RTSP 



^ 



6. RTSP SETUP (Asset URL, Re 



7. 200 OK, Seission ID 



8. Extract SDP 



9. RTSP PLA^^ 



10. Content stream(s) 



iources_Conf_ID) 



V" 



Figure B.2: CoD session initiation 

User selected CoD asset during SD&S process. UE has received asset URL. 

1) The UE sends RTSP SETUP to the IPTV control with the asset URL. 

2) The IPTVC control selects MCF. 

3) The IPTVC control reserves resources between MDF and UE. 

4) The IPTVC control returns selected MCF in the REDIRECT message. 

5) TCP connection for RTSP is established between UE and MCF. 



NOTE 1 : Optionally RTSP method DESCRIBE may be used before SETUP to request media delivery initialization 
information from MCF if the parameters have not been sent by IPTV control within REDIRECT 
sequence (1 to 5). 
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6) The UE sends RTSP SETUP to the IPTV control with the asset URL. 

7) The CoD-MF sends 200 OK with SDP. The SDP contains the session descriptions of UDP/RTP stream to be 
used. 

8) Optionally, the UE extracts the media descriptions from the SDP of 200 OK. 

9) The UE sends RTSP PLAY command. 

10) The CoD-MF starts sending UDP/RTP content streams to the UE. 

NOTE 2: If coupled mode is used for CoD procedure the steps 1 to 4 are not needed (procedure start from step 5). 

NOTE 3: After successful authorization of the service request, the key exchange and delivery of security metadata 
to the UE may be initiated in accordance with the media content protection model as described in 
TS 187 003[i.l7]. 

B.3.2 CoD Session termination 
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CoD MF 



TCP Connection for RTSP 
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Content streann(s) 



1. RTSP TEAR DOWN (optional Re sources_Conf_ID 



2. UDP Content Stream is ternninated 



3. Resource Release 



4. 200 OK 



Figure B.3: CoD session initiation 

1 ) TEARDOWN request is sent to CoD-MF. 

2) CoD-MF stops sending UDP/RTP content streams. 

3) The CoD MF requires for RACS to release resources. 

4) The CoD MF responds with 200 OK response. 



B.4 Signalling flows of BTV with trick modes 

This clause describes an example of signalling flow of BTV session initiation and termination. BTV with trick modes is 
a superimposition of BTV and CoD sessions in a single service as discussed in [4]. 

The switch from BTV to trick modes is shown in figure B.4. 

ECF/EFF is typically a part of the Access Network as shown on TS 182 028 [4], figure 4. 



ETSI 



72 



ETSI TS 183 064 V3.4.1 (2011-02) 



UE 



ECF/EFF 



RACS 



bTV stream 



1 . Multicast Repcirt (Leave) - Pause 



CoDMF 



bTV channel 



Resource Release 



2. RTSP SETUP (Asset URL) 




3. Select CoDMCF 



4. Reserve and Comnit Resources between MDF/MDF BGF and UE 



5. RTSP REDIRECT (MCF adcress, Resources_Conf_ID, 



6. Est TCP Connection for RTSP 
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k 
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Figure B.4: BTV with trick modes: switch to trick modes 

User is watching BTV channel and wants to initiate trick mode. 

1) The UE sends a multicast leave request (Membership Report Message (IGMP) or Multicast Listener Report 
Message (MLD)) to stop receiving multicast media stream. 

NOTE: Local resource reservation and admission controlled is performed by the ECF/EFF as defined in [3]. 

2) The UE sends RTSP SETUP to the IPTV control with the asset URL. 

3) The IPTV-C control selects MCF. 

4) The IPTV-C control reserves resources between MDF and UE. 

5) The IPTV-C control returns selected MCF in the REDIRECT message. 

6) TCP connection for RTSP is established between UE and MCF. 

7) The UE sends RTSP SETUP to the IPTV control with the asset URL. 

8) The CoD-MF sends 200 OK. 

9) The UE sends RTSP PLAY command. 

10) The CoD-MF starts sending UDP/RTP content streams to the UE. 
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B.5 Signalling flows of Push CoD 
B.5.1 Push CoD procedures using notification 




MF 
MCF & MDF 




IPTVASF 
(CFIA) 



UPSF/ 
lUDF 



1 . Subscribe to Push CoD service 



3. Accepted 



6. UE accept cont(^nt 



5. Deliver Notification about Push Cc D content to UE 



2. Check profile & notification 
Push CoD rules 



4. Push CoD event 



7. Push CoD content is delivered to UE 



Figure B.5: Push CoD services procedure 

The detailed description of procedure is following: 

1) User subscribes to Push CoD service using Tr reference point. 

2) According to policies the CFIA may request IPTV sub-profile of federalized user profile over Ud interface. 
CFIA decides user authorization to use a service based on received information and service logic. 

3) CFIA authorizes request and confirms successful subscription to the UE. 

NOTE: IPTV Service provider may initiate Push CoD without explicit user subscription in which case 1 to 3 may 
be optional. 

4) New Push CoD event acts as a trigger for CFIA. 

5) CFIA delivers notification to the UE (including CoD content identifier) using notification framework. 

6) UE may accept delivery of Push COD. 

7) IPTV-C initiate towards MCF/MDF PushCOD deHvery to UE by one of following option: 

CoD content delivery (as described in clause 6.1.2) then stream is stored as file in UE for later PushCOD 
consumption. 

BC content delivery (as described in clause 7.1.1) then stream is stored as file in UE for later PushCOD 
consumption. 

CoD content download from MDF (as described in clause 6.1.6 follows [5], clause 10). The content may 
be either viewed immediately or stored for later vie wings. 
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B.6 Signalling flows of Near CoD 
B.7 Signalling flows of Interactive TV 



UEs 



UE 
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UPSF/ 
lUDF 
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2. Check user profile ( k authorization 
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5. Interactive TV application 



6. Terminate Interactive TV application and release resources 



Figure B.6: Personalized Interactive TV applications 

1) After UE discovers interactive IPTV application via SD&S then send HTTP request GET for service initiation 
of selected iTV from CFIA using Tr reference point. Request may contain UE id and also required 
authorization. Depending on iTV application HTTPS may be supported. 

2) CFIA optionally checks user profile, requests authorization and information for service personalization. 

3) CFIA requests Common NGN ASF to setup interactions with external ASFs, if external ASFs are used. 

4) In case of proxy mode all communication goes via CFIA. In cease of redirection, External ASF replies to 
CFIA with URL and iTV service description. 

5) CFIA replies to the UE optionally attaching information for initiating and using interactive TV application. 

6) UE initiates by HTTP request personalized interactive IPTV service (e.g. interacting with application or with 
other users) towards CFIA (direct mode or proxy mode) or external ASF (redirect mode). 

7) UE requests termination of Interactive IPTV application. CFIA releases all resources allocated for the 
interactive TV applications. 



B.8 Signalling flows of IPTV Notification 

IPTV ASF (CFIA) shall support notification mechanism to deliver notification Message to the IPTV UE using HTTP 
delivery over Tr reference point. 

The procedure is applicable for notification mechanism used in the following services: 

Notification Service. 

Notification based TAI. 

User generated content. 

Content Recommendation. 

Emergency alerting. 
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• Incoming call management. 

• Client PVR. 

• Content/Service availability notification (e.g. Push CoD, UGC). 




IPTVASF 
(CFIA) 



1 . Notification event 



2. Deliver Notification 
message to UE1 



3. 200 OK 



4. Notification presented to UE 
or service action 



n r 

Figure B.7: IPTV Notification services to IPTV UE 

The description of the protocols and messages illustrated below: 

1) When notification event occurs either through external triggers or by decision of CFIA service logic, IPTV 
ASF (CFIA) initiates notification and composes Notification message using XML schema defined in annex C. 

NOTE 1 : CFIA may request information from IPTV user profile and check service policies. 

2) CFIA sends notification message to the UE (via HTTP and Tr interface) which contains XML notification. 

NOTE 2: Two options have been identified so far for HTTP notification mechanisms: persistent HTTP session 
and/or UE browser listener on the known port. 

3) The delivery is confirmed by HTTP 200 OK response to the CFIA. 

4) The notification information may be presented to the user or trigger UE internal action, for example UE 
initiated IPTV services. 

NOTE 3: Notification methods use HTTP over Tr interface. 

User actions can be delivered together with the notification and user selection passed back to IPTV ASF (CFIA) for 
processing, i.e. to simplify message processing on the UE and remove specific message processing logic from the UE. 
In this case XML schema defined in annex C is used. 
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B.9 UE start up and service attachment 

Figure B.8 presents functional steps of the UE start-up procedure for NGN Integrated IPTV. The procedure follows [4], 
clause 6.3.1. 
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Figure B.8: UE start-up procedure 

1) UE shall perform network attachment via el reference point. Protocol usage shall comply with el reference 
point. During this step, the UE attaches to network and may acquire network identification, e.g. IP address. 
The UE may be passed additional data for Service Provider Discovery (SPD) as defined in [4], clause 6.3.2. 

2) UE shall discover service providers and services from SD&S. SD&S shall apply conforming to 

TS 102 034 [5], clause 5.2 as discussed in [4]„ clause 6.3.2 and in clause 5.1.1 of the present document. 

3) During this step UE, bootstrapping function and IPTV service provider are involved in initial IPTV security 
bootstrapping processing as defined in [4] and in TS 187 003 [i.l7], clause 9 and follows TR 187 013 [i.l]. 

After successful mutual authentication between the UE and Bootstrapping function the UE tries to access the 
IPTV service. UE and corresponding IPTV service control entities may derives appropriate keys from key 
management entities (as initial steps of service protection and content protection mechanisms). 

4) UE shall attach to the IPTV Service and request service selection via Tr interface using HTTP. 

5) UE obtains IPTV Service offers. 

During steps 4 and 5, UE navigates and selects a service from available service offers. IPTV AS may update IPTV user 
profile, presence and other applications of behalf of IPTV. Service navigation and selection can be provided in a generic 
case via different functional entity as presented on figure 10 in TS 182 028 [4]. 
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Annex C (normative): 

XML Schema for IPTV notification, messaging and user 

interaction 

C.1 XIVIL notification schema 

This annex defines XML schema for IPTV Notifications. AppHcation of IPTV notifications is defined in 
TS 182 028 [4]. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www. w3 . org/2 OOl/XMLSchema" 

xmlns :uep="urn:org:etsi :ngn:params :xml :ns : iptvnotif ication" 

elementFormDefault=" qualified" 

attributeFormDefault= "unqualified" > 

<xs: element name="IPTVNotif ication" type="tIPTVNotif ication" /> 
<xs : complexType name="tIPTVNot if ication" > 
<xs : annotation> 

<xs :documentation>XML Schema for NGN IPTV Notif ications</xs :documentation> 
</xs : annotation> 
<xs : sequence> 

<xs: element name=" Identifier" type="tIPTVNotif icationldentif ier" /> 
<xs: element name="Message Type" type="tIPTVNotif icationType" /> 

<xs: element name= "Reference Message Identifier" type="tIPTVNotif icationldentif ier" 
minOccurs=" 0" maxOccurs="l"/> 

<xs: element name=" Expiry date" type="xs rdateTime " minOccurs=" 0" maxOccurs="l"/> 
<xs: element name=" Sender Information" type="tIPTVInf o " minOccurs=" 0" maxOccurs="l"/> 
<xs: element name= "Recipient Information" type="tIPTVInf o " minOccurs=" 0" maxOccurs="l"/> 
<xs: element name= "Action" type="tIPTVNotif icationAction" minOccurs="l" 
maxOccurs= "unbounded" /> 

<xs: element name="Notif icationDescription" type="tIPTVNotif icationDescription" /> 
<xs:element name=" Extension" type="tExtension" minOccurs=" 0" maxOccurs= "unbounded" /> 

</xs : sequence> 
</xs : complexType > 

<xs : simpleType name="tIPTVNotif icationldentif ier" final="list restriction" > 
<xs : restriction base="xs : string" > 
<xs rminLength value="0"/> 
<xs rmaxLength value="16"/> 
</xs : restriction> 
</xs : simpleType > 

<xs : simpleType name="tIPTVNot if icationType" final="list restriction" > 
<xs : restriction base="xs : string" > 

<xs : enumeration value= "Notif ication" /> 

<xs : enumeration value= "Update" /> 

<xs : enumeration value="Cancel"/> 

<xs : enumeration value="Time Shift "/> 

<xs : enumeration value="Ack"/> 

<xs : enumeration value="Error"/> 
</xs : restriction> 
</xs : simpleType > 

<xs : simpleType name="tIPTVInf o" final="list restriction" > 
<xs : restriction base="xs : string" > 
<xs rminLength value="0"/> 
<xs rmaxLength value="64"/> 
</xs r restriction> 
</xs r simpleType > 

<xs r element name="tIPTVNotif icationAction" type="tIPTVNotif icationAction" /> 
<xs r complexType name="tIPTVNot if icationAction" > 
<xs r sequence> 

<xsr element name="ActionType" type="tIPTVNotif icationActionType" /> 
<xsr element name="ActionTypeDescription" type="tIPTVNotif icationDescription" /> 
</xs r sequence> 
</xs r complexType > 

<xs r simpleType name="tIPTVNot if icationActionType" final="list restriction" > 
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<xs : restriction base="xs : string" > 

<xs rminLength value="0"/> 

<xs : maxLength value="16"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : simpleType name="tIPTVNotif icationDescription" final="list restriction" > 
<xs : restriction base="xs : string" > 
<xs rminLength value="0"/> 
<xs : maxLength value="25612 8"/> 
</xs : restriction> 
</xs : simpleType > 

<xs : complexType name= " tExtension" > 
<xs : annotation> 

<xs : documentation> 

This element is reserved for further extensions 
</xs : documentation> 
</xs : annotation> 
<xs : sequence> 

<xs:any processContents="lax" minOccurs=" 0" maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType > 
</xs : schema> 



C.2 Notification delivery mechanisms 

Notification delivery mechanisms should comply with one of the following methods: 

• Metadata is encoded in XML (W3C XML). 

• Application event record can optionally be encoded in XML. 

• Metadata and application event record encoded in XML can optionally be compressed by using Fast Infoset 
(ITU-T Recommendation X.891 [i.l4]), ZLIB including GZIP format (TS 102 472 [i.l5]) or BiM 
(ISO/IEC 23001 [i.l6]). 

Delivery of IPTV notifications may support one of the methods: 

• HTTP version 1.1 IETF RFC 2616 [9] for application event or metadata delivery over unicast. 

• HTTP over TLS IETF RFC 2818 [41] for application event or metadata delivery over unicast with secure 
manner. 

• Optionally Session Initiation Protocol (SlP)-Specific Event Notification RFC 3265 [18]. 

Notification mechanisms should applicable for notification used in the following services with specified 
"tIPTVNotificationActionType" : 

Notification Service (tIPTVNotificationActionType=NotifySer). 

Notification based TAI (tIPTVNotificationActionType=NotifyTAI). 

Content Recommendation (tIPT VNotification ActionType=ContentRecom) . 

Emergency alerting (tIPTVNotificationActionType=Emergency). 

Incoming call management (tIPTVNotificationActionType=CallID). 

Client PVR (tIPTVNotificationActionType=cPVR). 

Content/Service availability notification (e.g. Push CoD, UGC) (tIPTVNotificationActionType=CoD, PcoD, 
EC, UGC). 

User interaction (tIPTVNotificationActionType=Interaction). 

Messaging (tIPTVNotificationActionType=Message). 
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Where tIPTVNotificationDescription may contain: 

• Text (e.g. string with text message with possibiHty include hyperhnks, buttons, etc.). 

• ContentID (e.g. to IPTV content like CoD, PushCoD, UGC, BC, etc.). 

• URL to content (e.g. picture, video, audio and multimedia). 

• Presentation type (e.g. show in pop-up, in PiP, not show, etc.). 

• Or any combination of listed above. 

C.3 Mapping to ITU-T IPTV framework for notification 

ITU-T Notification framework is supported by TISPSAN NGN IPTV Notifications schema. This annex illustrates 
mapping between TISPSAN NGN IPTV Notifications schema and ITU-T framework for notifications. 

Table C.1 : Mapping between TISPAN IPTV Notifications and ITU-T IPTV framework for notification 



ITU-T IPTV framework for notification 


TISPAN IPTV Notifications 


Note 


Identifier 


Identifier 


REQUIRED 


Message Type 


Message Type 


REQUIRED 


Reference Message Identifier 


Reference Message Identifier 


OPTIONAL 


Expiry date 


Expiry date 


OPTIONAL 


Sender Information 


Sender Information 


REQUIRED - ITU 
REQUIRED -TISPAN 


Event Information 


Action 

Notification Description 


REQUIRED 


Recipient Information 


Recipient Information 


REQUIRED - ITU 
REQUIRED -TISPAN 


Forward Information 


Not supported 


OPTIONAL - ITU 


Not supported 


Extensions 


Optional - TISPAN 
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Annex D (normative): 
UE capabilities 

UE supports following specifications: 

• HTTP: 

HTTP protocol shall be used conforming to [5] and follow standard HTTP [9]; 

HTTPS [41]; 

HTTP Digest [7] is recommended on the Tr interface; 

MD5 is recommended digest algorithm as defined in [19], MD5 Message Digest Algorithm; 

UE shall support HTTP notification mechanisms based on persistent HTTP connection (as in [9], 
clause 8.1) and UE listening on known multicast address for HTTP/XML message; 

UE should implement an http compliant web browser with JavaScript for: 

One or more markup languages, such as HTML, XHTML and SVG (e.g. XHTML 1.0 [31], 
HTML-5 [i.ll]); 

Standard profiles of style sheets (e.g. CSS 2 [32] or CSS TV profile [33]); 

Standard scripting language (e.g. ECMAScript [34] or JavaScript); 

Document Object Model (e.g. D0M2 [35]); 

XMLHttpRequest ( [36]). 

NOTE 1 : A particular implementation of the web browser is outside the scope of the present document. For 
example the web browser could be based on technologies described in ITU-T 
Recommendation H.760 [i.3], annex A, (e.g. CEA-2014 or DVB-HTML). 

Information about UE capabilities and supported browser profiles shall be included in user profile (UE 
capabilities). UE should access IPTV profiles (including UE capabilities) via Tr interface using XCAP (as 
described in clause 5.1.2). 

To minimize compliance and interoperability issues UE shall minimally provide a CE-HTML [51] web 
browser with XHTML 1.0 [31], CSS TV profile [33], DOM 2 [35], ISO/IEC-16262 [34] (ECMAScript) 
support. 

NOTE 2: The UE can support one or more standard browsers technologies (CE-HTML, DVB -HTML, SVG, 
Mobile browsers) and browser profiles (examples of browser profiles are described in ITU-T 
Recommendation H.760, [i.3] annex A). For example the web browser profile could be based on 
following combinations of web technologies: 

1) CE-HTML profile ([51]) (default) - XHTML 1.0, CSS TV profile, DOM 2, ISO/IEC-16262 
(ECMAScript). 

2) DVB-HTML profile ([i.7]) - XHTML 1.0, CSS 2, DOM 2 , ISO/IEC-16262 (ECMAScript). 

3) SVG profile [i.8] - SVGl.l: CSS 2, DOM 1, DOM 2, ISO/IEC-16262 (ECMAScript) or SVG Tiny 
([i.9]): CSS 2, uDOM, ECMA ISO/IEC-16262 (ECMAScript). 

4) Mobile profile ([i. 10]) - XHTML, OMA Mobile Profile. 



ETSI 



81 ETSI TS 1 83 064 V3.4.1 (201 1 -02) 



• RTSP: 



Support of RTSP methods in NGN integrated IPTV as described in clause 6 (based on RTSP usage 
in [5]); 

Optionally HTTP Digest Access Authentication can be applied to RTSP control messages as defined 
in [19]. 

• IGMP/MLD: 

If Ipv4 is used for the transport, the UE shall support IGMPv3 as described in [20] ; 
If Ipv6 is used for the transport, the UE shall support MLDv2 as described in [21]. 

• Transport and encapsulation based on [5] : 

The UE shall be able to receive the content encapsulated into MPEG2TS over RTP conforming [5], 
clause 7.1.1 and MPEG2TS over UDP conforming [5], clause 7.1.2. 

• DVBSTP: 

If DVBSTP for multicast (which is optional for UE) is used then it shall conform to [5], clause 5.2. 

• SIP: 

For SIP capable UE interactions with messaging services, SIP MESSAGE should used conforming 
to [10]; 

For SIP capable UE interactions with notification services, SIP SUBSCRIBE and SIP NOTIFY should 
be used conforming to [18]. 

• FLUTE: 

UE should support FLUTE for multicast content download delivery as described in [30], [5]. 
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Annex E (normative): 

XML Schema for sync parameters 

E.1 Mime Type for inter-destination media 
synchronization 

The Mime Type "application/vnd.etsi.iptvsync+xml" is used in HTTP to signal the use of the XML schema of 
annex E.2 for inter-destination media synchronization. The use of this Mime Type and XML schema is specified in 
clause 5.L16.L 

The XML Schema shown in annexes E to I are contained in archive ts_183064v030401p0.zip which accompanies the 
present document. 

E.2 XML Schema for inter-destination media 
synchronization 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www. w3 . org/2 OOl/XMLSchema" 

xmlns :uep="urn:org:etsi mgnrparams :xml :ns : sync" 

elementFormDefault=" qualified" 

attributeFormDefault= "unqualified" > 

<xs: element name="SyncGroup" type="tSyncGroup"/> 

<xs : complexType name="tSyncGroup" > 
<xs : sequence> 

<xs : element name="RtcpXrSyncGroupId" type="xs :nonNegativeInteger"/> 
<xs : annotation> 

<xs : documentation> 

RtcpXrSyncGroupId is a 32 -bit unsigned integer 
in network byte order and represented in decimal. 
</xs : documentation> 
</xs : annotation> 
<xs: element name="Ssrc" type="xs :nonNegativeInteger"/> 
<xs : annotation> 

<xs : documentation> 

Ssrc is a 32 -bit unsigned integer 

in network byte order and represented in decimal . 
</xs : documentation> 
</xs : annotation> 
<xs: element name="RtcpPort " type="xs : string" /> 
<xs : annotation> 

<xs : documentation> 

Encoding of an IP address (Ipv4 or Ipv6) plus port number. 
Ipv4 example: 139.63.192.106:53020 
Ipv6 example: [2002 : : : : : : 8b3f : c06a] : 53020 
</xs : documentation> 
</xs : annotation> 
</xs : sequence> 
</xs : complexType > 

</xs : schema> 
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Annex F (normative): 

XML Schema for content bookmark 

F.1 XML schema for content bookmarks 

This annex defines XML schema for IPTV Content bookmark. AppHcation of IPTV content bookmark, e.g. for session 
continuation or "park and pick up" and flows are defined in TS 182 028 [4]. 

CoD, nPVR, tsTV content bookmark may contain relative timestamp (NPT), absolute time offset (UTC) or absolute 
byte offset inside ContentOffset. The value should comply with offsets defined in RFC 2326 [6]. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema targetNamespace="urn:org: etsi mgnrparams :xml :ns : iptvcontentbookmark" 

xmlns="urn:org:etsi mgnrparams :xml :ns : iptvcontentbookmark" 

xmlns :xs="http : //www. w3 . org/2 OOl/XMLSchema" elementFormDefault= "qualified" 

attributeFormDefault= "unqualified" > 

<xs : element name= " IPTVContentBookmark" > 
<xs : complexType> 
<xs : sequence> 

<xs: element name="BookmarkedContent" type="tBookmarkedContent" minOccurs="0" 
maxOccurs= " unbounded" / > 

</xs : sequence> 
</xs : complexType> 
</xs : element> 

<xs : complexType name= " tBookmarkedContent " > 
<xs : sequence> 

<xs: element name="ContentId" type="xs : string"/> 
<xs: element name="BookmarkType" type="tBookmarkType"/> 
<xs: element name="ContentOf f set " type="xs : string" minOccurs="0"/> 
<xs: element name="ExpiryTime" type="xs rdateTime" minOccurs=" 0"/> 

<xs:element name=" Extension" type="tExtension" minOccurs=" 0" maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType > 

<xs : simpleType name="tBookmarkType" final="list restriction" > 
<xs : annotation> 

<xs : documentation> 

<label xml : lang="en">Bookmark class</label> 

<definition xml : lang="en" >Specif ies the type of bookmark </def inition> 
</xs : documentation> 
</xs : annotation> 
<xs : restriction base="xs : string" > 

<xs : enumeration value= " Failed" > </xs : enumeration> 
<xs : enumeration value= " Parked" > </xs : enumeration> 
</xs : restriction> 
</xs : simpleType > 

<xs : complexType name= " tExtension" > 
<xs : annotation> 

<xs : documentation> 

This element is reserved for further extensions 
</xs : documentation> 
</xs : annotation> 
<xs : sequence> 

<xs:any processContents="lax" minOccurs=" 0" maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType > 
</xs : schema> 
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Annex G (normative): 

XML Schema for Content Description 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www. w3 . org/2 OOl/XMLSchema" xmlns :uep="urn: org: etsi :ngn:params :xml :ns : 

contentdescription" 

elementFormDefault= "qualified" 

attributeFormDefault= "unqualified" > 

<xs: element name="ContentItem" type="tContentItem"/> 

<xs : complexType name="tContentItem" > 
<xs : sequence> 

<xs: element name="ContentId" type="xs : string" /> 
<xs: element name= "Title" type="xs : string" /> 
<xs: element name= "Originator" type="xs : string" /> 

<xs: element name=" Great ionTime" type="xs :dateTime" minOccurs=" 0"/> 
<xs: element name= "Genre" type="xs : string" minOccurs=" 0"/> 
<xs: element name= "Description" type="xs : string" minOccurs=" 0"/> 
<xs:element name=" Extension" type="tExtension" minOccurs=" 0"/> 

<xs:any namespace="##other" processGontents="lax" minOccurs=" 0" maxOccurs= "unbounded"/:; 
</xs : sequence> 
</xs : complexType > 

<xs : complexType name= " tExtension" > 
<xs : sequence> 

<xs:any processGontents="lax" minOccurs=" 0" maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType > 

</xs : schema> 
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Annex H (normative): 

XML Schema for the IPTV profile 



This annex referring to XML schema for creating documents representing instances of the IPTV profile described in 
annex C of TS 183 063 [17] and may be used by NGN integrated IPTV services. This XML schema is used when IPTV 
profile is manipulated with the XCAP procedure described in clauses 5.1.2 and 13. 
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Annex I (normative): 

XML Schema for Content Playlist 

1.1 XML schema for content play-list 

IPTV content play-list is a logical collection of physical assets which can be played together a single 'virtual' asset for 
linear or on-demand NGN Integrated IPTV services. Normal service flows should apply for the respective service type. 

Content playlist can be used for following services: 

• Personalized Channel. 

• Targeted Advertising (ad insertion). 

This annex defines XML schema for IPTV content play-list. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema targetNamespace="urn:org: etsi : ngn : params :xml :ns : iptvcontentplaylist" 

xmlns="urn:org:etsi : ngn: params :xml :ns : iptvcontentplaylist" 

xmlns :xs="http: //www. w3 . org/2 00 l/XMLSchema" elementFormDefault=" qualified" 

attributeFormDefault= "unqualified" > 

<xs : element name="IPTVContentPlaylis" > 

<xs: element name="PlaylistName" type="xs : string" /> 
<xs: element name="ExpiryTime" type="xs rdateTime" minOccurs="0"/> 
<xs : complexType> 
<xs : sequence> 

<xs: element name="PlaylistItem" type="tPlaylistItem" minOccurs="l" 
maxOccurs= "unbounded" /> 

</xs : sequence> 
</xs : complexType> 

<xs:element name=" Extension" type="tExtension" minOccurs=" 0" maxOccurs= "unbounded" /> 
</xs :element> 

<xs : complexType name="tPlaylistItem" > 
<xs : sequence> 

<xs: element name="ContentId" type="xs : string"/> 

<xs: element name="StartContentOf f set " type="xs : string" minOccurs=" 0"/> 
<xs: element name="StopContentOf f set " type="xs : string" minOccurs=" 0"/> 
<xs:element name=" Extension" type="tExtension" minOccurs="0" maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType > 

<xs : complexType name= " tExtension" > 
<xs : annotation> 

<xs : documentation> 

This element is reserved for further extensions 
</xs : documentation> 
</xs : annotation> 
<xs : sequence> 

<xs:any processContents="lax" minOccurs="0" maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType > 
</xs : schema> 
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